Usage of Imgur hosted images

[user_5589]

It is safe to assume all of my images are licensable under that licence. All were photographed by me.

[Matija_Nalis]

I understand both the urgency and hugely appreciate @Pieter_Vander_Vennet effort to save those images!

However, I also agree with @Mateusz_Konieczny - randomly assuming authors and licenses is not really acceptable.

It is acceptable (to me) that MapComplete hosts all those images with unknown authors/licenses (and their original Imgur URLs) if the risk of potential copyright infringement is acceptable to them (as it is likely easily solvable by promptly reacting to any cease & desist letters they might potentially receive; and there is a low risk of people having hosted images on Imgur being annoyed enough by re-hosting to another place; especially in the danger of them being lost).

However, it is IMHO much more problematic to basically make up invalid copyright claims / licenses - and picture authors are more likely to get riled up about that. So I would advise against incorrectly claiming that most popular license actually covers all of them.

I also get @roelant issue of too-shortly discussed automated edits breaking existing stuff (even if it does help better solution being implemented faster).

---

All that being said, I would suggest interim solution, for those imgur pictures that were not uploaded via MapComplete (but by other authors using other methods):

• for initial phase, after re-hosting, just change their image=* link from https://imgur.com/ to https://panoramax.mapcomplete.org/, instead of removing image=* and replacing it with panoramax=*

  That way, such information would remain visible (and without duplicates) in all current data consumers. And number of MapComplete have already bumped panoramax=* tag to big enough number to use it as a leverage to get data consumers to support it.

  Actually, it would be even nicer if @Pieter_Vander_Vennet stored original Imgur URL and implemented a redirector. So if picture had e.g. image=https://imgur.com/a/OZ27uqi, replace it with image=https://oldimgur.mapcomplete.org/a/OZ27uqi and make that website a redirector which would do 301 HTTP redirect to https://panoramax.mapcomplete.org/whatever_new_url_is – doing so would make it easier to follow, allow other (non-OSM) projects that also relied on those images to easily recreate a link to them (or re-fetch images for their own use).

• some months (or years) later, when mostly every data consumer which cares about pictures supports panoramax=* tag, do (after a proper mechanical edits discussion) a final replacement from image=https://panoramax.mapcomplete.org/xxx to panoramax=xxx; as that will not break things at that time.

That should minimize the problems, for not too much extra effort.

[Pieter_Vander_Vennet]

Just to be clear, there are two issues here: the properly licensed images and the rest.

The properly licensed issues are all moved by now.

I didn’t touch the rest of the images for now. There is clearly no consensus on rehosting those images without the permission of the original uploader; but the easiest approach here is probably to request permission to the owners. WIth contacting about 15 people, we might be able to rehost about 80% of the images, which is good enough IMHO.

I’m not gonna implement a redirector - that is a ton of work for no actual added benefit.

[roelant]

@Pieter_Vander_Vennet

Hi Roeland,

Yes, I understand this is a bit of a surprise (…)

First of all, thank you for taking the time to get back to me so elaborately.

If those pictures however mimicked the attribution format that MapComplete uses, they are indistinguishable from “real” MapComplete images for the script that I used. I also checked for the “CC0”-keyword in the description, which caused a few more pictures to be moved, including yours.

Yes, and here’s why my images contained that keyword: as part of the recommendation to put them on imgur “for now” (among other things so they would be included in the backup), it was mentioned that I should add the CC0 licence for them to be legally usable for openstreetmap - and so I did. So that’s of a bit of a catch 22, isn’t it?

Let me be very clear: I’m not trying to assign blame here to whoever recommended that to me (because I know this person is reading along), I’m just pointing out the unintended consequences of earlier recommendations and later assumptions.

On top of the catch22, I can’t speak for others, but mine were (and are) actually distinguishable. Because mine never contained just the CC disclaimer, but also the link to the POI('s) they were added to, for my own practical purposes (example).

One of the main arguments is that people might remove duplicate images “because they are duplicate”, especially if they are not aware of the underlying implementation. Then, they might randomly delete either the imgur (getting in the current situation) or the panoramax (permanently breaking the image in the future).

But that’s - in general - a problem we face with OSM and not exclusive to these two tags.

Edit, the morning after: come to think of it, this argument could also be reversed: people might re-add an image “because there is none”, causing unnecessary (or at least extra/duplicate) effort, and/or different imagery based on what tag is supported by the data-consumer (which could actually be an argument that a proper implementations means showing both, with some sort of deduplication built in, more on that below).

I’d also like to mention the core OSM-pragma “Don’t tag for the renderer”. I’m not gonna make the data and the process more complicated (and it complicates a lot) because your prefered rendering solution (OsmAnd) doesn’t yet support panoramax.

I agree, but that argument literally goes both ways: you’re deleting them because where it does get rendered, it would show duplicate in your preferred render/data-consumer (assuming MapComplete). That’s just another form of tagging for the renderer.

One could argue that deleting data for proper rendering is even more harmful then keeping it in multiple formats (which happens with a lot of tags, e.g. zebra’s).

One could also argue that a proper implementation on the side of the renderer is able to hander duplicates, same as when wiki is linked in multiple ways (Id, name), in which the Panoramax-ID is just another way to link to an image also present in the image-key.

Because how otherwise to handle the various situations in which [1] they are the same [2] they are different [3] only one is present (either new images added trough MapComplete/only present on Panoramax, the images you couldn’t touch/move still on imgurl, newly added images by people who are blissfully unaware of Panoramax and your initiative/change/quest - either on imgur or elsewhere).

With respect to “grace period”: how long should this grace period be? Until major apps have panoramax support? What is a “major app”? What if a major app decides to not implement it? How much of the major apps should support this?

That’s obviously subject to debate, and something that should have been debated beforehand (not before adding Panoramax, but difinately before deleting imgur-URL’s

I’m assuming there’s stats out there somewhere of the most used ones, as there are for editors, and yes, going by the bigger ones seems reasonable.

And this is not a black and white kind of thing. There’s best practices for software sunset and sunrise, which is basically what this is, for a tag. To my knowledge, a good grace period is anything between a month and a year, depending on how big the required change is for the implementing party.

And if the situation changes, then the decision can be revised:

• big player not implementing? revise threshold.
• imgur suddenly deleting > x% of the images? move deadline forward (and communicate why and when propely to all stakeholders).
• etc.

We did the effort to reach out to some of them (including osmand and OpenAED-map).

Which is appreciated. But as a developer yourself, I think you would’ve (also) appreciated the issue feature change request being reported before the change breaks something, instead of after?

How much of a heads-up would you personally have preferred if you were on the receiving end of things, as the (by your own admission: sole, pressed for time) MapComplete developer? That is probably a good first indicator of what a fair outgoing grace period would’ve been, too.

At last, I am indeed forcing the hand of the other developers by also removing the images. I’m aware of that and I would like to apologize for the stress and inconvenience that this causes them. However, by making this move, there are suddenly 35K objects with a panoramax-tag. This is a good incentive for app developers to support it. At the end of september, there were less then 2K such objects. As app developer, I don’t want to put in effort for tags that are under 10K objects. (And no, this isn’t an argument for removing the image tags, I know this)

Since I agree with your closing remark, what is the point you’re making here? You could’ve supported Panoramax without removing the imgur-images, so unless I’m missing something, this is not relevant to the discussion we’re currently having about a grace period?

Also: it is a fun part of psychology that one complains about moving the pictures, but not about the new pictures that are available exclusively through panoramax. If panoramax would have been around 4 years ago and MapComplete used this right from the start, we wouldn’t have this discussion.

Adding new images exclusively to Panoramax is your choice as a developer - and something your users can now accept up front by using your tool. If I’d be a MapComplete user and my goal would be as described in my first post, I would’ve also manually added the image tag, or used a different tool to make sure the images appear in my preferred application (or theirs).

So your psychology is only partially right: with new images, the MapComplete users have this choice up front, without having putten in any effort, without breaking previous images that they already put effort in. Not to mention non-mapcomplete users such as myself who put in even more effort (manually uploading, manually adding them to an object), who’s effort has now also been undone.

I’ve been “educated” (as a mapper) with the notion that deleting data previously added by others should be done with the utmost care for the fact that you’re undoing someone’s effort, erasing knowledge and information, that it should therefore be given very careful and deliberate consideration and only done if the data is really wrong. It feels to me like that step of consideration has been skipped here - even if unintentionally and out of enthousiasm for the new solution.

I’m not going to pretend my personal effort is such a big loss. Maybe 3 or 4 images all together, with a bunch more queued up that are a drop in the ocean compared to others. But on a principle basis, I strongly disagree with the premature removal of the image-tag in general, breaking them in renderers/data-consumers without having really given them a chance to catch up, instead of facilitating some sort of transition period. To my mind that’s a dark stain on what’s otherwise a greatly appreciated and valuable effort.

To add to that, it seems to me that some of the consequences in terms of “two keys offering the same type of data, while data consumers may support only one, the other, or both” has not been been fully thought trough.

 
Edited the morning after: Added in clarifications and some thoughts that followed later, fixed readability.

[lipuma]

Hi Pieter,

While I appreciate you saving images uploaded to Imgur by uploading them to Panoramax, I don’t understand why these mass edits weren’t discussed with the community in each country?

At least not in the Netherlands, I can’t find any thread in our community where this mass edit was discussed. I believe this is against the automated edits code of conduct.

Or am I missing something? Maybe you could give me a link to a discussion with the Dutch community? I understand many people encouraged you, because “imgur bad, panoramax good”, but the process, ups and downsides and more could’ve been discussed before performing this mass edit.

[draconic_mapper]

As I stated before, I support a move from Imgur to Panoramax, but doing so forcefully and without proper discussion in the community is not okay. OSM is a community project after all.

@Pieter_Vander_Vennet would it be acceptable to re-add the image tags, at least for now? They can be either the original Imgur link or a direct link to the Panoramax image.

You stated before that the reason for removing the link is to prevent duplicate images. However looking at the source for openaedmap for example I see that only one image is ever show. Are there any other projects that do show duplicate images?
Even if this is the case I don’t think this is as big a concern as not showing an image at all, which is what is happening in multiple places no. It would also not be too hard to ignore duplicate images in the application.

As a final note, please also consider how decisions like this change peoples perception of Panoramax. I can very well imagine that a developer or user that suddenly sees their images are gone is left with a negative impression of Panoramax, especially if it is their first time hearing about the project. Forcing users to switch without proper notice is generally not received well, and has killed many a project in the past. It would be a shame if this where to happen to Panoramax.

[roelant]

@Pieter_Vander_Vennet

About the “community consent”: I’ve had exactly 3 people complaining about “removed images”.

(…)

I did however get way more encouragements and “thank-you”-messages then this. Everyone recognizes that this is a necessary move. And indeed, there is always a tradeoff to be made on how this is handled, how much communication is done to the community, what grace period to use, what time I have available, the risk of IMGUR blocking us of completely…

I’ve considered not responding to this separate reply, because it feels like a very subjective perception and it’s hard arguing with perceptions.

But since we talked psychology earlier, I think a similar approach here is permissible as well, and I’ll share my perception in return. Because your perception makes sense from your perspective, but it’s flawed on more then one level from my end.

#1

Before looking into it more because images were missing, I’ve came across and read Moving images from Imgur to Panoramax. Based on just that, I would’ve belonged to the “thank you, great job!”-group and no more. And here’s why.

Without clicking trough to the linked GitHub issue (which according to Discourse only 4 people did, including me just now), it sounds like you’re only moving the images from one host to another and replacing the URL accordingly, without removing the image-key.

I know of Panoramax, seen it, but never realised that this wasn’t just about moving them, but also a different implementation all together. Basically removing the image-tag (with its clickable link to an actual image) and replacing this with the panoramax-tag which contains a hash which currently isn’t clickable yet, and isn’t yet supported by the majority of data consumers/editors.

I’m pretty sure that if the title was “Deleting 30k+ image-links and replacing them with Panoramax-hashes” you would’ve been met with a lot more resistance - it could be an interesting experiment to still do that.

It could even be argued that this announcement was misleading in those respects. Now to be clear, I don’t want to assume negative intentions here nor accuse you of same, but even looking at it as positive as possible, it did falsely assume everyone knows what Panoramax is - and how using Panoramax would significantly differ from using imgur.

That basically it was a announcement (because in fairness, it doesn’t even read as a proposal) enhances this notion: deleting 30k+ tags surely would justify a proposal/discussion (see #2 below), rather then an announcement, right?

I’m surpressing the urge to insert some applicable memes in here, but I’m not sure it would be appreciated as intended.

#2

Moving images from Imgur to Panoramax is also the closest we came to “discussing the mass/mechanical edit”. But wasn’t properly labelled or written as such, didn’t cover fully what what the change entails, and in general doesn’t meat the requirements as put down by the Automated Edits code of conduct.

On a side note, the code of conduct has both arguments against and in favour of how you proceeded, but the key here is: it should’ve been discussed beforehand (clearly, with all implications clearly put out there, not hidden behind a link).

#3 / In conclusion

Because it was “announced” and not “proposed”, did not clearly explain what the actual impact was, I think it’s also fair to assume that the people who’ll be reaching out are:

1. Either people who know you, were already involved and/or in the know, and therefore to be considered similarly subjective to the approach, or…
2. Didn’t grasp the scope of the change, just considered it replacing one host (URL) for another, and a commercial one for something open source at that, “so sure, thumbs up!”. Or: "imgur bad, panoramax good”, as @lipuma nicely put it.

Hence, generally positive.
 

Having said all that, I’d be in favour of restoring the image-tags as proposed by @draconic_mapper, until such a time that discussion has taken place and community consent has actually been asked - and subsequently given. Opt-in, and not opt-out, if you will.

[Pieter_Vander_Vennet]

Hi all,

These are all some very valid points. I’m thinking about temporary adding image tags for legacy use.

However, before doing this, I’d like to know what an acceptable timing is until removing this again. 3 months? 6 months? Until a certain piece of software supports this? Which pieces?

[roelant]

Hey, thanks for considering that, I really appreciate it. The timing of your response is also impeccable, because I actually have a related question that’s probably part of the answer to your question - and was about to send you a DM about that (because it might actually need to be a separate discussion/topic and feels slightly off-topic here).

There’s a lot of sub-questions (or potential follow-up questions) to my question, but in the end it comes down to: to what degree are panoramax and image-keys to be considered “the same” (in terms of purpose/goal, expected result, expected implementation, etc), and therefore “mutually exclusive”?

The more I’ve thought and read about it, also seeing a recent example you gave on Mastodon, the more I have a feeling that they aren’t the same thing at all.

Similarly to Google offering both Streetview (“an ability to virtually walk over the street and look around” - aka primarily 360º imagery) ánd pictures of POI (“a static picture that shows you what the thing looks like”). When there’s no streetview available, the pictures are shown, and vice versa. There’s an overlap, but they’re not the same thing.

I wonder if that’s an approach we could/should consider here (too). Where the one’s already happening (Panoramax showing regular pictures if no 360º is available), and (therefore) consider adding a https://api.panoramax.xyz/api/pictures/{hash}/sd.jpg-style link to the image-tag (at least when no other imagery is available) as well as filling the panoramax-hash by default to achieve the other.

I know this is not the exact/immediate answer to your question, but I hope you understand why it’s related to my mind (and perhaps a prerequisite to determining if and when they should be removed again).

[Pieter_Vander_Vennet]

Panoramax is developed as alternative to Mapillary. The main goal of that piece of software is to host 360° (and normal) pictures. The French want an alternative to Google Streetview.

As MapComplete, we took this piece of software and used it primarily as “image host” to replace IMGUR. This has some added benefits, such as being compatible with iD and many other pieces of software (but it should be said that the ecosystem around this is very young and immature; but many tools are adding support, partially thanks to our effort of poking them and having a proverbial carrot of 35K images).

As such, one should compare it to Mapillary. One could use “Mapillary” too (but those links get often broken by Mapillary or drop you in their webapp). But we are using it a little bit as a replacement for the image tag (with more).

[Ltrlg]

The panoramax key is defined as a link to a specific image, not a location, hence more on the side of “a static picture […]” (360° or not).

For “[…] look around”, no key is required as it should be easy (eventually?) to build a link to (or even integrate) the Panoramax viewer from the coordinates of the object.

[Thibaultmol (Thibault Molleman)]

correct, it’s always to a specific image.

For a link to ‘open current location in panoramax’ it’s just a question of linking to
https://api.panoramax.xyz/#map=ZOOMLEVEL/LAT/LON