image_1 image_2? Brycenesbitt 08:48, 31 August 2011 (BST)
- I would prefer image:1=*, image:2=*,…. Is there any Tag wich could exist multiple times on one Node/Way (like maxspeed=* but without a further description (z.B. maxspeed:forward=*))? --rayquaza 06:26, 20 May 2012 (BST
- Normally, if it's one tag with multiple values, it's separated with ;-symbols. --Sanderd17 15:45, 27 October 2012 (UTC)
- It's not normal to do this, please don't spread this mistaken notion. Semicolons are only supported well for a handful of tags: see Semi-colon value separator. In this case it is particularly problematic because the ";" character is use in URIs as a reserved sub-delimiter. Any confusion here will break RFC3986 because if an URI's ";"s are encoded as "%3b"s, then the resultant URI is not equivalent.
- Spaces are better if values are just URIs. Integer ":"-delimited suffixes (in the key) are fine too.
- --achadwick (talk) 13:47, 16 June 2013 (UTC)
Copyright of the images
The subject of copyright should be addressed. How can one verify the copyright status of the linked image, preferably via automatic means? Unless there is certainty that each image has a free (as in freedom) license allowing commercial use, very few people and/or legal entities would want to risk displaying them. Who would the potential users of this feature be if this is the case? This can probably work for images on Wikimedia commons where the license status can be verified, but not guaranteed if freeform URLs are allowed. -Svavar Kjarrval (talk) 01:26, 13 June 2013 (UTC)
- Yes and no. OSM can store direct links without legal problems. Also, the links can be displayed on an interactive map. But only the links. The images may not be displayed in maps without checking the license. And here we come to the essential point. What use OSM links to images that may not show the renderer? What good are the user of the card images that he did not free may use? These questions should provide a free project like OSM is especially. We have the aim to provide the user with free data. Furthermore, we expect all users of OSM that they observe and comply with our Linzenz. Consequently, one must expect from OSM that OSM and the other subsequent users also note the license rights! For this reason, History Map was developed for a specific solution in coordination with the German community already many months ago. This requires that images are displayed only after verification of the license on the map. For this reason, we have already pointed out on several occasions to give the free pictures from Wikimedia Commons preference. At this point I would also like a little more detail to explain the same: To check the license of an image, it is necessary that not hotlink the image is stored in OSM. Rather, it is always necessary to refer to the image description page with the disclosures on the usage rights (license). To anyone who thinks that http://commons.wikimedia.org/wiki/File:Semperoper_Dresden.jpg a hotlink is completely wrong. This link leads to the image description page, which has to read the renderer to display the image may. Only in this way, it is ensured that the renderer (and viewer) receives the license information. The procedure in example Flickr is identical. Another possibility is the release of the "robots.txt" file (see Historische Objekte#Bildvorschau). Please follow the German text. The translation was created with Google.
- It seems I'm partly responsible for stopping the vote, so I want to help revive the discussion. As I understand it, what makes this tag complicated is that we don't just want to link to an image, but be able to show it directly in a slippy map or other application, which requires us to deal with the image's license.
- To allow as many su(Translation: ch use cases as possible, I think we should only link to images under free, well-known licenses (that is, mostly CC0, CC-BY, CC-BY-SA). In other words, only add images that can be used for all the same purposes as OSM itself. CC0 or PD images would of course be the easiest because they don't require any legal text to be retrieved and displayed, and if they are available I would always give preference to them.
- For those images whose licenses require attribution or otherwise special treatment, there needs to be a public API or other means to automatically extract the information required for display. Of course, we have to be aware that a data consumer will still have to write special code for each image hoster, so images that are not on Commons or certain other big sites will likely be ignored. I don't see a good way to avoid this in the general case. However, the approach from "Historische Objekte" (as linked by Reneman above) is interesting - it appears that it allows for smaller sites that would probably not get individual treatment to declare their images' availability for embedding in OSM-based maps via robots.txt.
- --Tordanik 11:08, 23 June 2013 (UTC)
- Shortcut format image=File:image.jpg specifies an image on WikiMedia Commons.
- Dieser Kurzlink funktioniert wahrscheinlich nur auf der Geschichtskarte. Warum bleibt man nicht bei image=url? keep-right zeigt Fehler an und andere Maps zeigen kein Bild. Seit dem dies auf der Seite image= steht nutzen einige Mapper die Kurzform - ich finde das falsch.
- --Geri-oc (talk) 12:32, 30 August 2013 (UTC)
- Translation (not my opinion): This shortcut is probably only supported on the History Map. Why don't you stick with image=url? keep-right is flagging errors and other maps do not show an image. Since this has been mentioned on the image= page, some mappers have been using the short form - I think that's wrong. --Tordanik 21:20, 30 August 2013 (UTC)
Vote started early
The proposal failed to wait for the required two weeks between RFC and vote. Please to back to RFC for now - I believe there is enough left to discuss, especially with regards to licensing of the linked images. --Tordanik 12:55, 16 June 2013 (UTC)
VOTE PULLED BACK PER ABOVE JUNE 2013
Here's a record of the voting. The most significant issue raised is verifying the license status of the linked image. The solution in the German historical map was to link to an index page that defines the licence, not the image itself Brycenesbitt (talk) 21:05, 17 June 2013 (UTC)
- I approve this proposal. It's ok. --Zverik (talk) 18:11, 15 June 2013 (UTC)
- I approve this proposal. Look good. We need to make this tag uniform. Glassman Glassman (talk) 00:27, 16 June 2013 (UTC)
- I oppose this proposal. This proposal does not deal with licensing rights, a disgrace for a free project. This proposal does not deal with the difference Hotlink and image information page. But "http://commons.wikimedia.org/wiki/File:Semperoper_Dresden.jpg" is not a Hotlink! Read the DISK. This Proposal has no example for mappers. Read in German.
- I approve this proposal. It's ok. es geht um den image=* tag an sich, unabhängig der lizenz-problematik....... --lutz 12:00, 16 June 2013 (UTC)
- I oppose this proposal. --vvoovv (talk) 11:35, 16 June 2013 (UTC) This tag will create a mess. Use a separate database server to store links to images.
- I approve this proposal.It's ok. hno2 13:34 UTC 16.June 2013
- I oppose this proposal. Impractical without a limitation to images under a free, machine-parseable license. Also subjective. --Tordanik 12:43, 16 June 2013 (UTC)
- I oppose this proposal. image=* sollte auf eine url verweisen. Damit die Möglichkeit auf Beschreibung und andere Formate erhalten bleibt. --Geri-oc (talk) 13:10, 16 June 2013 (UTC)
- I approve this proposal. --Viking81 (talk) 21:42, 16 June 2013 (UTC)
- I oppose this proposal. use this if you like, but I don't think it makes much sense, better use an external database for image links and link them to fuzzy world objects. You could have much more than one link. An image is not a property of an object in osm --Dieterdreist (talk) 23:06, 16 June 2013 (UTC)
The proposal has been amended to specify the image tag as a link to an index page, one that defines the copyright status. Display agents are responsible for deciding if a particular image link is compatible with their licence requirements Brycenesbitt (talk) 17:06, 2 July 2013 (UTC)
Voting July 2013
Please keep in mind as you vote: this (and photo=) are widely used tags today. The intent here is in part to simply document what's already happening.
- I approve this proposal. Brycenesbitt (talk) 15:43, 2 July 2013 (UTC) (proposal proponent)
- I approve this proposal. Glassman (talk) 16:43, 2 July 2013 (UTC)
- I oppose this proposal. This proposal doesn't solve the issue of multiple images for the same feature. It cannot guarantee that the tag will not link to copyrighted material or ads or spam or whatever. It's scary to read that the tag is primarily intended to be consumed by software agents. OSM has to be used as basement for other projects, not as the interlink database of external projects, commercial or not. It has to work the opposite, these external projects (or images db in this case) have to link to OSM through geographic coordinates and feature type/name. This tag is just here to compensate the laziness of some web designers and programmers. Better work on the sustainable osm-id topic or check XAPI to link OSM elements to a picture. --Pieren (talk) 19:23, 2 July 2013 (UTC)
- I approve this proposal. Please continue with the image=File:image.jpg variant for commons images. /al 06:30, 3 July 2013 (UTC)
- I oppose this proposal. I can only see reasons against it, and none encouraging such a tag. OpenStreetView cannot (or little) benefit from it; who would ever check the "acceptability" of the link; what about multiple links or edition wars… I also globally agree (once more) with Pieren. --JB (talk) 16:12, 3 July 2013 (UTC)
- I approve this proposal. --Reneman (talk) 17:12, 4 July 2013 (UTC)
- I abstain. The clarification is a step forward, but I would like an explicit recommendation against linking non-free images. Also somewhat worried about the subjectivity. --Tordanik 17:42, 4 July 2013 (UTC)
- I oppose this proposal. There must not be a requirement ("must ... licence" in the first paragraph) for a machine readable licence information, or any of that sort. It's a link, it's up to the consumer to decide how to handle it. Alv (talk) 18:22, 4 July 2013 (UTC)
- I approve this proposal. --Lutz (talk) 14:34, 5 July 2013 (UTC)
- I oppose this proposal. ZITAT: "Alles Material auf den Commons muss unter einer freien Lizenz stehen ..." - also können die Dateien von OSM (und anderen) genutzt werden. Deshalb lade ich Bilder bei COMMONS - eingeschränkte Rechte haben m.E. nichts mit Commons (WIKI) zu tun. Und wenn ich ein Bild von meiner Website auf OSM verlinke, ist es meine Entscheidung, es öffentlich zu machen. Deshalb bin ich für Beibehaltung image=(url). --Geri-oc (talk) 14:04, 5 July 2013 (UTC)
- I oppose this proposal. --4rch (talk) 22:37, 6 July 2013 (UTC)
- I approve this proposal. erkinalp 05:38, 18 July 2013 (UTC)
- I approve this proposal. Popolon (talk) 11:56, 29 July 2013 (UTC)
I would like to propose additional metadata tags
image=URL or Filename reference image:url=raw URL to the image image:thumbnail=URL or Filename reference to a thumbnail image:thumbnail_url=resolved URL to the thumnail image image:thumbnail_embedding_allowed=yes/no image:license=CC BY image:author=Photographer image:source=URL to the page where the image is shown usually (i.e. Wikicommons File page) image:embedding_allowed=yes/no image:image_position=lon,lat,alt image:camera_position=lon,lat,alt
The image:url could be such a URL derived from a Filename or ID reference from a provider (Wikicommons, Panoramico etc.). Because sometimes providers change their URL schema. Then new URL could be derived form the Filename reference. It would be a comfort function for the renderer to get the URL quickly.
In the current definition, the File: reference prefers only one provider. Better:
then you can also write
... and to simpilfy tagging: this image=FileWikiCommons:image.jpg could be sufficient info for Images from this provider, to auto-accept the license, auto-generate the urls, previews etc.
I don't know about embedding policies. It's usually always allow to publish a link that a browser can follow. It's usually a problem to include an external image into own pages or services. One can resolve this by an extra field ...embedding_allowed=yes/no or assume this for known providers --Oosm12 (talk) 14:25, 3 November 2013 (UTC)