Talk:Key:image

Page content / key description

Chrabros was "Trying to define the tag according to Map Features". I have reverted this preliminary. Should we just set such a definition without discussion? Hmm … Where was the discussion for the addition/description on Map Features? Thank you --Aseerel4c26 (talk) 13:27, 27 February 2014 (UTC)

OK. So let's discuss it. I was just extrapolating on the description given of MapFeatures page and on the content of this tag. Why you haven't reveted the description there, if you are so concerned about it?

And what was wrong with my description? Only the lack of discussion?

Do you have better description? Then write it here. Reverting is really easy...

Chrabros (talk) 14:09, 27 February 2014 (UTC)

I do not watch the Map Features page, so I did not notice it. Yes, I reverted mainly just to avoid establishing a potentially new meaning of a already widely used tag. In principle here in the wiki there is the proposal process to define meanings of tags, but you seem to intentionally wanting to skip it. ...which may be okay.

Reverting back to your description is easy too!

One issue: "link to the image" and mentioning URL/URI seems to imply that a image should be directly linked. This is only useful in case of public domain images. Otherwise the attribution and license mention is missing. So in that cases a link to a HTML page containing the image and attribution may be useful / may be used.

I do not want to read the old proposal now. I will come back to this later. Note that you do not need to copy the page content to here (including categorization...). Still accessible in the history, I had already mentioned the link in my comment above. Do not get crazy, please. --Aseerel4c26 (talk) 14:35, 27 February 2014 (UTC)

Unfortunately, your description does not take the feedback from the two failed proposal votes into account 1 2. Specifically:

• The subjectivity of the image choice, and the inability to link more than one image.
• Whether images should be limited to platforms (e.g. Wikimedia Commons) that offer a machine-readable license or CC0 content to allow legal re-use.
• Whether the linked image should be required to be under a free license.

Each vote ended without the required number of participants, by the way.

As for Map Features, its content is split across a lot of templates, so almost no one has the entirety on their watch list. As a result, a lot of edits are slipping through unnoticed. --Tordanik 15:20, 27 February 2014 (UTC)

I am not mad, but I an not excited as well.

And I am not skipping anything. The proposal process is for proposing a new tags etc. I was not proposing anything I was just copying (and adding a little bit) from another place on the same wiki (which you did not bother to read).

I have Map Features on my watch list and it is really not difficult to keep up.

Well, the proposal was still linked there.

Yes, I have deliberately omitted the content of the proposal, as it is proposal. So I was just trying to describe the current state and in those two lines I have stated that the definition is not really good one.

Still, I believe that both lines I have added are true.

So, what now? Chrabros (talk) 15:31, 27 February 2014 (UTC)

You were essentially proposing a "new" key. The page was empty before. I wrote that I will get back to this issue, but I just realized that I should not invest my scarce time here, sorry. Tordanik summarized it good. What now? You can write on the page that the key's meaning is discussed - add this talk page to the "see also" section. So everybody can view your proposed version. --Aseerel4c26 (talk) 18:01, 27 February 2014 (UTC)

Well, I still think that you do not see it, or do not want to see it. I was not essentially proposing a new key. I was just copying its description from MapFeatures page. And because the description there was not really clear I just extrapolated little bit from the current values of data.

I still believe that my two lines description is consistent with the rest of wiki and key's usage.

Tordanik is right that there might be a notice to those three problematic points. But this could be added to the page instead of deleting it.

Also there is a STUB template use which just says "try to improve the page". I have tried.

Tordanik, do you agree with reverting to my version, emphasizing that there was no proposal process for this key and adding those three problematic points you mentioned? I would like to see some content there as I do no like keys with no definition at all. Chrabros (talk) 03:04, 28 February 2014 (UTC)

All things considered, I think that adding text explaining the points of disagreement could indeed be a reasonable solution. Even if one does not want the key to be used, the current blank page isn't really preferable - people might that the tag does exist and the explanation page has simply not been written yet. So I'd offer to modify your version to explain the controversy. Is that acceptable for everyone? --Tordanik 16:30, 28 February 2014 (UTC)

You were proposing a new key definition, because you added the content to this page (which may be seen as the truth™ by some people). Yes, you just copied, but those other pages are not that relevant - however the definition slipped in there. However, thank you for wanting to fill in the stub, really. Adding a minor issue: you mentioned "URL" - I guess some people may only add filenames of files which can be found in this wiki (maybe indirectly accessing Wikimedia Commons).

Tordanik, good luck in trying to be neutral. :-) --Aseerel4c26 (talk) 20:41, 28 February 2014 (UTC)

The page is now updated and available for fine-tuning or complete rejection. But I hope I have been successful in fairly including all viewpoints. --Tordanik 02:41, 1 March 2014 (UTC)

Thanks, fine for me. I made some small changes/additions. --Aseerel4c26 (talk) 11:54, 1 March 2014 (UTC)

Hi, I like it very much. It is actually much better then similar page elsewhere. Nice work. :-)

Two questions though:

Do you really believe that Key: page is more important than the entry in Map Features page? I got the impression that it is vice versa. First the link to Map Features is third link in the main menu which kind of says that it is really important. Also I believe that many readers read just the Map Features page for a short summary and do not go into any more details on Key or Tag pages {this is even more valid for non English speaking users as the Map Features page is translated among first). Sure, there are many inconsistencies between Map Features and relevant Key and Tag page and when I am translating I am trying to fix that if I can. But I would say that the info on Map Features if of greater importance.

Is possible linking to a copyrighted image really a problem? The image must be displayed on the web either by an author or possibly someone else. But if we provide a link to it it does not sound as we break any more copyright rules. Or are there countries where you can link only with author permission?

Chrabros (talk) 04:44, 2 March 2014 (UTC)

I am never looking up on Map Features (takes long to load). Sometimes on DE:How_to_map_a. But most often on key/tag pages. And regarding the description on Map Features: you see it differs from the actual key usage.

"Copyrighted" images: a link likely (! … IANAL) is not a problem in most countries. But if a user of OSM data displays the image after clicking on a POI (e.g. in a popup on a map), then it likely really IS an issue. It is a slippery slope. Courts sometimes have interesting viewpoints. And in general: we are part of the free / open content community and should encourage other free content. Makes our data more usable! --Aseerel4c26 (talk) 13:32, 2 March 2014 (UTC)

I also rarely visit Map Features. The concept of the page is to only show the most common and popular tags, which lends itself more to newbies. Those tags are generally also the ones which I know already and which are also available as editor presets. For my own mapping, I usually use the search function, taginfo, or go directly to a specific wiki page if I know the name. And if I explain something on forum/help I definitely link the Key/Tag page. But Map Features might still be helpful for others, especially beginners.

As for the copyright of images, I think Aseerel4c26 has already covered that. --Tordanik 12:12, 3 March 2014 (UTC)

PS: When I wrote "aborted votes" on Key:image, I meant the two proposal votes that were cancelled before the standard 2 weeks voting were over and before the quorum of 15 voters was reached, respectively. I hope I phrased that correctly, English is not my native language. --Tordanik 12:21, 3 March 2014 (UTC)

OK, got it. I am glad that the content of this page is much more pleasant than it was. :-)

I think that it would be "cancelled votes" rather than "aborted votes" and quick google search seems to confirm it. But who knows maybe native speakers will call it different way. Chrabros (talk) 06:14, 4 March 2014 (UTC)

Yes, that seems better to me. Confirmed by 3 to 0 results ("cancelled vote" vs. "aborted vote") in English Wikipedia text. Changed. --Aseerel4c26 (talk) 11:37, 4 March 2014 (UTC)

Limit to Wikimedia Comons?

Why don't you simply limit this use case to wikimedia commons, by using a new tag wikimedia_commons=, similar to Key:wikipedia? It would resolve most issues (access to license, no linking of untrusted sources, obsolete URLs, etc.), and implementations can still check this older image= tag for supported values. Also would be in spirit of free information access, as these projects are similar minded. Also would encourage users to share their OSM photos of historical places to Wikimedia Commons. Kempelen (talk) 21:02, 13 July 2014 (UTC)

Agreed. I would also point out that when dealing with panorama images, that they also take away a lot of the spamming / subjective problems, as a panorama image there is no single chosen angle, allowing spammers to highlight commercial signs etc. Panoramas, taken from a uniform height, provide a pretty objective representation of *everything* around a specific set of geo-co-ordinates. To me it seems that pano images, uploaded to Wikimedia Commons, under a free license, should present very few of the presented issues at all. Even non-pano images under this proposal seem like a significant step up. In the same way that we currently can extract a wealth of data from the Bing maps arial photographs (while they still allow us access), open licensed, street level images would give potential access to add a lot of verifiable data to mappers who couldn't physically get to a location, in the same way that we can currently add many items to the map via tracing Bing Maps. RoadLessTraveled (talk) 05:35, 16 September 2014 (UTC)

But what happens when there is a category of images on Wikimedia Commons? It seems to me that, in this case, the wikimedia_commons tag should contain the category. As a result, there would no longer be an opportunity to link a single image, and the choice of images in applications would be effectively random. --Tordanik 15:18, 16 September 2014 (UTC)

I'm in favor of the wikimedia_commons= tag. Most wikipedia pages of places have a single prominent photo. Take http://en.wikipedia.org/wiki/Ballard_Park_(Melbourne,_Florida), as a random example. It seems the osm editors could in most cases choose a single photo. There are many applications where being able to display a single photo would be helpful. Additionally, this would promote sharing between the two projects. Brianegge (talk) 16:13, 18 November 2014 (UTC)

You could select also a specific image inside a category:
wikimedia_commons=Category:Eiffel Tower#/media/File:Eiffelturm.JPG.
Pyrog (talk) 16:51, 1 November 2019 (UTC)

Why would you want to do that? All Commons file names are unique, so you could just as well use File:Eiffelturm.JPG --Hjart (talk) 17:01, 1 November 2019 (UTC)

I discovered with taginfo this usage (not documented before).
Without that, OSM contributors use image=* with the full URL of a "best" picture, and wikimedia_commons=* with the category containing other images of the OSM object.
With this syntax, you don't need the image=* and don't have to use the full URL.
Pyrog (talk) 00:46, 2 November 2019 (UTC)

Read also Why Category:xxxx#/media/File:yyyy syntax is Controversial ?

--Pyrog (talk) 11:56, 10 November 2019 (UTC)

For those interested, there is a discussion on this going on on the new forum, see Restrict wikimedia_commons URLs as image=* tag values? -- Emvee (talk) 21:30, 29 August 2022 (UTC)

Unresolved issues

As mentioned on the main wiki text, this tag as several issues:

1. Only one image can be linked to any Openstreetmap feature with this tag.
2. The selection of the image is subjective and might be biased or abused for commercial and advertising purposes.
3. Attribution and licensing requirements for the linked image are unclear and might be missed by a direct link.
4. Other third-party databases offer the option of adding images about a certain feature, for example Mapillary and wikimedia_commons=*.

See Key:image#Unresolved issues as well. --Jeisenbe (talk) 02:16, 23 January 2020 (UTC)

> 1. Only one image can be linked to any Openstreetmap feature with this tag

We could use multiples values separated by ; (but in API v0.6 the length is limited to 255 bytes)

Same issue with mapillary=*, wikimedia_commons=*, flickr=*… maybe on day openstreetcam=*

> 3. Attribution and licensing requirements for the linked image are unclear and might be missed by a direct link.

So if image=* is still used, we must discourage direct link (full URL to i.e. Wikimedia or Mapillary images)

And all major OSM sites/tools must provide a link to the image "official" page (with attributions) i.e. :

• fQ8XXRxHgBnD6qg4uUUi0A
• File:Stolpersteine,_Grindel,_Hamburg.jpg
• 1291965/18
• 98121773@N02/23904134458

Could be done with regular expressions, but it's simpler to code if we use separate tags for each image providers.

--Pyrog (talk) 13:46, 7 May 2020 (UTC)

> 1. Only one image can be linked to any Openstreetmap feature with this tag

MapComplete is using additional image:0 image:1 ... tags

--Cyril42e (talk) 01:49, 30 May 2022 (UTC)

Adding image tags to objects with Wikimedia_commons tags?

I recently noticed https://www.openstreetmap.org/changeset/79455777 in which a user practically duplicates the info found in the existing wikimedia_commons=* by adding an image=* to the same photo found on Commons. To me "semantically different" sounds like merely a bad excuse. I'm leaning towards strongly discouraging this practice. Any other opionions? --Hjart (talk) 09:59, 23 January 2020 (UTC)

+1. The same happens for mapillary tags where a direct URL to the image is added as well. The reason given by the mappers is usually "because $APP doesn't resolve the links". --Mueschel (talk) 10:34, 23 January 2020 (UTC)

I agree this is bad practice. It seems like tagging for the renderer instead of using the tags wisely and in a consistent manner.--PangoSE (talk) 10:47, 23 January 2020 (UTC)

Personally I see no big problems with this practice, though I would not do this Mateusz Konieczny (talk) 18:55, 23 January 2020 (UTC)

It does add one more place which needs to be changed in case the image is renamed or deleted or someone wants to select another image for the object. Personally I definitely wouldn't be a big fan of having to handle that. --Hjart (talk) 21:51, 23 January 2020 (UTC)

Discourage linking to commons files and migrate all File:filename.* values and direct urls to wikimedia_commons

Hi, I suggest we clean up this tag in the database to see the extent of its use and the problems associated with it.

To do that intelligently I suggest we migrate all Wikimedia Commons File:filename.* values to wikimedia_commons as well as all image= urls directly to commons files to the wikimedia_commons= tag with the proper syntax. See Automated edits/pangoSE#Key:image

This (and perhaps all) use of the image= tag should also be clearly discouraged on the wiki-page.

This consistency is important to renderers like OsmAnd which is planning to soon support the wikimedia_commons tag and render the image/images when clicking on a POI.

See also the discussion on tagging. WDYT?--PangoSE (talk) 10:51, 23 January 2020 (UTC)

Note Automated Edits code of conduct. Though maybe handling it as a validator rule in JOSM/iD may be more likely to be accepted. Mateusz Konieczny (talk) 18:56, 23 January 2020 (UTC)

Spreading images across multiple tags depending on where they are hosted doesn't seem very clean to me. Wouldn't it be far cleaner to move all image links to image=*, so that wikimedia_commons=* could always be used for categories? --Tordanik 17:51, 3 February 2020 (UTC)

That might be "cleaner" (depending on perspective), but please no. Someone on the mailing list suggested moving wikimedia_commons=* to commons_file=* and commons_category=*. Personally I like that a lot more. --Hjart (talk) 22:15, 3 February 2020 (UTC)

I agree with hjart. Lets have clear tags where we mix as little when it comes to URI/URL as in this case. I'm designing a map over all huts and shelters on the plaanet with images in a popup. It is much easier for me to code if I can avoid having to match on the image tag whether it is a category, a file or any URL. Thank God no one yet started adding mapillary image URIs also to the tag, which would just make it harder. Did any of you see my suggestion above for fixing this with automated edits?--PangoSE (talk) 08:42, 4 February 2020 (UTC)

"Did any of you see my suggestion above for fixing this with automated edits?" Yes. Why you asking? Are you planning to propose such edit (see Automated Edits code of conduct) and run it? Mateusz Konieczny (talk) 16:10, 4 February 2020 (UTC)

License

How "free" should the image link be? Should you be able to open it with without JavaScript, with LibreJS, without DRM, having a patent-free encoding, without tracking, without registration, etc? Do you think the image itself needs to be compatible with the DFSG for some reason, or do you only want to be assured that anybody has permission to mirror it to mitigate a potential loss? If it's the latter, CC-NC-ND could also be acceptable. Bkil (talk) 23:52, 14 December 2022 (UTC)

The image is most helpful if it can be used in all scenarios in which OSM data itself can be used. To achieve this, the image should be under an open license, in an open format (which I would assume to include no DRM and no problematic patents), and it should be possible to automatically retrieve the image and the required attribution, e.g. through some well-known API. One test case could be: Can a commercial OSM-based app make this image available for offline use? --Tordanik 12:42, 18 December 2022 (UTC)

Copyright is mostly involved where you are participating in "copying" (i.e., distribution). It doesn't matter what license the image has if you are only caching it on your own device. That is equivalent to leaving the image on your screen all day long without shutting off the device - they can't prevent that (without DRM that is). See https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32000L0031&from=en#:~:text=Article%2013 But I already feel this to be an unjustified restriction. You can also find OSM-based online map apps for your mobile, so I don't see why we should limit ourselves for offline use. Neither do I see why your second sentence should be consequential from the first. Let's assume we agree upon the first sentence (you being able to use the image anywhere where OSM data can be used) Why is the image itself having an "open" license a precondition to this? What do you mean by "open" exactly here anyway? Bkil (talk) 13:07, 18 December 2022 (UTC)

Note that while private user may have no problems, but website author or app author that provides this data maybe may run into legal issues Mateusz Konieczny (talk) 16:56, 18 December 2022 (UTC)

I have linked to the applicable legal protection. Could you perhaps clarify your scenario so I can help you with it? Bkil (talk) 21:28, 18 December 2022 (UTC)

Note that at least in USA context you then need to deal with DMCA takedowns. And this text alone is long enough and complex that I would prefer to not risk me misunderstanding it, and would prefer to use only media where I am sure that I can use it and advise the same Mateusz Konieczny (talk) 06:26, 19 December 2022 (UTC)

I'm not a lawyer, but I'm not sure whether DMCA would apply here. I think it is more about you distributing copyrighted content (such as the image). [1] However, in case of OSM, we only add its URL to the database, not the base64 encoded data of it. But also, even if the OSMF have received a takedown about a given image, the remedy is just to revert the edit that added it (and ideally purge it from the database as well as per standard redaction procedure). I would be surprised if it took more than a page of code to automate this for this specific case. Bkil (talk) 20:38, 21 December 2022 (UTC)

A typical scenario for apps with offline capabilities is that the app developer provides "map packs" for download. If those contain images, that's not just caching, that's copying and redistribution. --Tordanik 19:25, 19 December 2022 (UTC)

I understand, but why would I, as a map editor be concerned about data consumers repackaging and selling OpenStreetMap in various ways? It is their responsibility to verify the licenses that are compatible with their business needs and it is they who need to consult with their lawyers. If they want to sell OSM contributions and they can't bother to do a even just a little work for it, they can just as well use one of the existing structured tags that provides licenses: wikimedia_commons=*, mapillary=*, kartaview=*, wikipedia=*, etc. Contributors have already placed completely random URLs within image=* they found through search engines or the site of the given POI and they will probably resume to do that in the foreseeable future. There is no way you want to go through each existing contribution or to retrospectively apply such a rule. If you want change, I would support introducing a new key to mark the image license, though, such as image:license=* (to possibly unify with license=*, copyright=*, source:license=* and source:licence=*. Bkil (talk) 20:33, 21 December 2022 (UTC)

It is affecting all users of this data presenting it in public, not only ones trying to earn profit on this. What is point of contributing data that is a trap for potential users? Mateusz Konieczny (talk) 22:25, 21 December 2022 (UTC)

"What do you mean by "open" exactly here anyway?" - with license that at least allows distribution Mateusz Konieczny (talk) 16:56, 18 December 2022 (UTC)

That's more reasonable, but I wouldn't call that open - that's just "shareware". But still, why and where would you like to redistribute the images linked to in url=*? The monopoly of Mapillary is caused by the fact that only deep pockets can finance mirroring. Bkil (talk) 21:28, 18 December 2022 (UTC)

I would be redistributed to users of website or app who look at OSM data. And it would be redistributed, as you need to get image to display it Mateusz Konieczny (talk) 06:26, 19 December 2022 (UTC)

If I print a URL of a photo of my favorite painting on my business card and I give it to you that you will type in at home to open in your browser, I am not distributing the photo. I would, had I printed the image onto my business card directly. It is the user who is accessing the page based on information she has learned. The page may be operated by the photographer herself and may decide to apply geo-fencing, advertisements or micropayments to view the image or revoke access to it within a second if they decide to sell it - in this case, it is the photographer doing the distribution that I don't influence at all. Similarly, if I only gave you the name of the search engine and exact search terms that will bring up the image in the first place, am I redistributing the image? Or I point to archive.org and similarly give you search terms that are expected to be durable for many years - better than URLs due to link rot! Bkil (talk) 21:02, 21 December 2022 (UTC)

When I say "open", what I have in mind are criteria like those defined in the OKF Open Definition. OSM grants all the permissions listed there. It seems pretty clear to me that, if an image's license does not grant the same permissions, then there will be a scenario in which OSM data can be used, but the linked image can not. --Tordanik 19:25, 19 December 2022 (UTC)

The source of most web pages is not "open", but we are similarly allowed to link to them. A link is just an opportunity for a user to look at it if she has the opportunity in the given situation. If they are in a situation when this would not be possible, the link can be hidden from their eyesight. This means we can provide value to at least some of our users (the great majority, I would recon). I think license integration is much more important for a tag such as 3dmr=*, as the data found at that URL will usually appear in the final rendering (such as a 3D printed map for the visual impaired), while photos are rarely printed on maps in a way that would assert derivative work or distribution clauses within copyright laws. Don't get me wrong: linking by itself may already be considered a federal offense at places (such as when you link to illegal content like warez), so asking to remove certain links and the OSMF keeping a domain/URL blocklist is absolutely warranted. It's just that links by themselves aren't bound by copyright laws in ways that some may believe. Bkil (talk) 20:54, 21 December 2022 (UTC)

Linking is fine, displaying their content on own website is (in general) not fine Mateusz Konieczny (talk) 22:28, 21 December 2022 (UTC)

Mention lack of hyperlink

a Wikimedia Commons filename (formatted as File:image.jpg) - although this is commonly tagged as wikimedia_commons

Mention that only the latter produces a hyperlink when viewed at <nowki>https://www.openstreetmap.org/ relation etc. / number </nowiki>.