Talk:Key:wikimedia commons

How to add multiple images to a single feature?

I'd like to add multiple images of single guidepost (eg. [1]). Many of the guideposts can't be covered by just one image. The problem is when it has signs from many directions. --*Martin* (talk) 20:25, 11 October 2016 (UTC)

Ideally you should link a relevant category or a galery page, but the tag allows just a direct link to an image (not even its description page, which is quite unfortunate). The doc anyway says that page names (instead of direct URLs) inncluding the File: or Category: namespace or no prefix for the galery page, is now accepted (and in fact even preferable to links which are restrincting to a single server or a single HTTP or HTTPS protocol, allowing the use of external proxies or local caches in applications).

instead I think that linking to the Wikidata entry would offer the best options of exploration (encompassing also the wikipedias with a single entry for all languages, even if we keep just one wikipedia in a default local language). — Verdy_p ^(talk) 20:53, 11 October 2016 (UTC)

Well I'm real sorry but let's take a boundary monument with a picture on country A's side. And another picture on Country B's side. There is no "best" one to pick without being partisan. So the only way to include them both is make an additional tag. And some markers are in three countries, so: tag, tag1, tag2. Jidanni (talk) 08:53, 4 Mar 2023 (UTC)

This is what I did with a guidepost: https://commons.wikimedia.org/wiki/File:Guidepost_Aga_(Casalzuigno).png

I made a collage of the two pictures, mentioned original sources and author in the description and released it with the same license. --Ivanbranco (talk) 10:16, 4 March 2023 (UTC)

You could use multi values: wikimedia_commons=File:pictureA.jpg;File:pictureB.jpg;File:pictureC.jpg and/or (like Philippe said) use wikidata=Q1234 and add several images in the wikidata item.

Be be carreful, both approach aren't supported by all apps. Also the value length of a tag is limited to 255 characters. So don't add to many values, and don't use too long names.

--Pyrog (talk) 10:59, 4 March 2023 (UTC)

Criteria for creating a commons category

"Anything having a Commons Category (not just a file) satisfies the notability criteria and is allowed to have a Wikidata entry. ", but what are the guidelines for creating new categories?

This question should go to the Commons wiki in their community page. Basically, a category is created when calssification of topics requires grouping them and an exisiting category becomes too large to find easily relevant files without additional criteria. There's some structure or ontology, but in fact Commonsis not the only player, and Wikidata also drives the overall organization of topics across all wikis, including but not limtied to Commons and Wikipedia.

Not all knowledge topics has articles in Wikipedia, or images in Commons to illustrate them, and there are even images that cannot be stored on Commons due to copyright restrictions or privacy or the local policy about some critical topics which may be offensive. So thre will exist categories in Wikiepdia with no matching category in Commons, or categories in Commons with no matching category in one or more Wikipedias. But Wikidata will collect data about all wikis and their particularities of what is suitable for one but not for another.

Authors have categories in Wikidata and in Commons because of their books or photos of their creation or personal photos in public events or in public job positions, but they have no key in OSM, as they are not themselves geolocalized. But they can have a Wikidata entry. — Verdy_p ^(talk) 00:16, 23 September 2017 (UTC)

Support on the OSM website

On the website it's possible to click through to images tagged with image=* (example: milestone milestone). People appear to be using that option because it "works".

If we are to promote the use of wikimedia_commons=* it would be good if we could similar click through to images/categories/pages (example: memorial stone memorial stone), right? After all this tag is the safer option?

• Your linked example probably works because it is a link. https://github.com/openstreetmap/openstreetmap-website is a place to suggest improvements to OSM webpage Mateusz Konieczny (talk) 21:13, 6 May 2018 (UTC)

I suggested it today: https://github.com/openstreetmap/openstreetmap-website/issues/2277 . So far it has been declined though. Maybe time to promote it some more? Personally I'm finding this tag really usefull even without website support. I'm even following some wikipedians, who take a lot of photos for their project, as a way to discover new areas worth mapping. --Hjart (talk) 16:38, 25 June 2019 (UTC)

OSM website display a link for wikidata=* and wikipedia=*, but not for wikimedia_commons=* ???!!!

This is the same foundation, and the "same" syntax.

See w62280106

--Pyrog (talk) 10:58, 7 November 2019 (UTC)

As of today the website displays wikimedia_commons=* links (see the conclusion of the github issue) :-) --Hjart (talk) 13:36, 8 November 2019 (UTC)

thanks - waited for years :-) ... Jo Cassel (talk) 15:53, 8 November 2019 (UTC)

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

I discovered recently this syntax. Not obvious at the first look.

Pro:

• avoid full URL in image tag
• avoid hassle to find the URL of the picture
• Apps supporting wikimedia_commons=* work with this syntax
• easy to get URL of category and file
  (just click on a picture in a category. Copy the URL, remove the "static" part. JOSM could do this automatically)
• OSM contributor use image=* key with the full URL probably because they don't know this syntax.
  They use the full URL because apps don't handle wikimedia_commons=* values in image=*.

Cons:

• "new"
• few documented
• others ??

--Pyrog (talk) 15:08, 6 November 2019 (UTC)

Why it would be better over wikimedia_commons=Category:XXXXX or wikimedia_commons=File:YYY syntax? All your "pro" applies also for this standard syntax. wikimedia_commons=Category:xxxx#/media/File:yyyy is less clear and there is subjective selection of image from category Mateusz Konieczny (talk) 18:15, 6 November 2019 (UTC)

• This is not better: this is an alternative usage founded in OSM database (probably by experienced wikimedia users ?)
• I agree that it is less clear (cf. my "Not obvious at the first look.")
• Of course there is a "subjective selection of image". This is the goal.
  Curently, OSM contributors set the wikimedia category AND specify a "subjective" image with the image=* tag.
  For OSM objects that have only e.g. a wikidata=* tag, the choice of the "subjective" image is done by the wikidata image property. Examples :
  • Alfred's Castle on gk.historic.place
  • Grafkelder Herckenrath on gk.historic.place

--Pyrog (talk) 09:07, 7 November 2019 (UTC)

As someone who contributed a lot of photos AND categories in Commons and a lot of Links in OSM

for example 674919702 674919702 please, please use

• image=https://commons.wikimedia.org/wiki/File:Bergpark_Wilhelmshöhe_-_Flora_2018-02-10_b.JPG
• wikimedia_commons=Category:Flora (Bergpark Wilhelmshöhe) -> https://commons.wikimedia.org/wiki/Category:Flora_(Bergpark_Wilhelmshöhe)

it works: http://gk.historic.place/historische_objekte/l/de/index.html?zoom=18&lat=51.31467&lon=9.41275&pid=HaHbHcSaHe&select=n674919702

and please avoid such strange ideas like Category:xxxx#/media/File:yyyy there is no need for this. ... Jo Cassel (talk) 18:27, 7 November 2019 (UTC)

Hi Jo,

Of course it work :)

And yes, this strange syntax (not idea please) is not yet supported especially by gk.historic.place.

I wrote an issue in this project and work with it developpers to solve it.

But sorry if I change the value of image=* too quickly (I could reverse it)

wikimedia_commons=Category:Flora (Bergpark Wilhelmshöhe) work and should stay "shorten".

Even in OSM website since today (because I discuss with devs and they accept after 5 years a pull request).

wikimedia_commons=Category:Gruab_va_Hardimbl#/media/File:Gruab_va_Hardimbl.jpg work in Overpass Turbo...

and even is OSM website : n4841942392 (one of your object that I edited too)

PS: I didn't invent this syntax, I just discovered it in taginfo

Best regards,

--Pyrog (talk) 00:17, 8 November 2019 (UTC)

What's the benefit of directly linking to the MediaViewer? It makes it more difficult to open the image full-screen in the browser.

Additionally I consider your linking style very unintuitive for humans and more difficult to parse with machines.--Buraq (talk) 02:29, 8 November 2019 (UTC)

PS: I didn't invent this syntax, I just discovered it in taginfo

@Pyrog But your are doing mechanical changes to propagate it.--Buraq (talk) 02:30, 8 November 2019 (UTC)

>What's the benefit of directly linking to the MediaViewer?

Specifying one category and one file with this key, without puting the mess in image=*

• Humans could read the key, see the picture and the category.
  • image=https://commons.wikimedia.org/wiki/Category:Linkens_M%C3%BChle#/media/File:185_Linkens_M%C3%BChle,_Haus_und_Hofanlage.jpg
    ->
  • wikimedia_commons=Category:Linkens_Mühle#/media/File:185_Linkens_Mühle,_Haus_und_Hofanlage.jpg

• machine could display the picture as they want (thumbnail, full screen…) with few lines of code
• the maintenance of OSM database is lower
• globally, the maintenance of the code is lower too

>Additionally I consider your linking style very unintuitive for humans

I agree that this syntax is not obvious. Category:xxxx#File:yyyy is better (but curently don't work with any software)

But moving File: from image=* to wikimedia_commons=* is not mandatory, especially if it already contain a Category: ;)

>and more difficult to parse with machines

• To link to the image, simply add https://commons.wikimedia.org/wiki/ before the value.
• To get the image page, get the last part with the following regular expression /(File:.*)$/
• To get the image itself, use wikimedia tools, i.e. Redirect by file, user, page, revision, or log ID
  • Get filename from i.e. File:Gruab_va_Hardimbl.jpg with regex /File:(.*)$/
  • Give https://commons.wikimedia.org/wiki/Special:Redirect/file/Gruab_va_Hardimbl.jpg

> @Pyrog But your are doing mechanical changes to propagate it

It was manual edits that change "only" 79 OSM objects : https://overpass-turbo.eu/s/NTt

I will do a revert tonight :)

PS: there is 1040 OSM objects with this syntax in image=* : https://overpass-turbo.eu/s/NUd

--Pyrog (talk) 08:25, 8 November 2019 (UTC)

Revert done :-)

--Pyrog (talk) 14:39, 15 November 2019 (UTC)

... and even is OSM website : n4841942392 (one of your object that I edited too)

the image-Link worked in the past, under image now under wikimedia_commons=Category:... as you can see at the natural monument nearby:

• https://www.openstreetmap.org/node/4841919689

see overpass turbo: http://overpass-turbo.eu/s/NVA

• the tree in the north 2019-11-08: Category:xxxx#/media/File:yyyy IMHO "merged shit"
• the tree in the south 2019-11-08: image=xxx AND wikimedia_commons:Category:yyy

please please stop your mission, if you want to "merge" OSM-Data -> you can do this in your own application as you like it. (and yes, the OSM-Homepage shoud render wikimedia_commons:Category:yyy as a Link, like overpass turbo does) ... Jo Cassel (talk) 14:35, 8 November 2019 (UTC)

My "mission" was stopped two days ago. I apologize if I hurt you.

As I said before, I will revert image=* to wikimedia_commons=*

Just to add my two cents: I believe some of the stated 'Pro' arguments aren't accurate.

• It's not true that applications supporting wikimedia_commons=* automatically work with this new syntax. If all the app does is to insert the static part of a link in front of it, that may be true. But if it wants to, say, download the image to embed it into a page, or obtain licensing information (which may be legally required to be displayed next to the image), they need to be updated for compatibility with your proposed syntax.
• The proposed syntax is quite hard to remember or write by hand, and it is only easy to get for people who arrive at the image viewer from a commons category page. I suspect many or even most people instead come from a Wikipedia page, or the image may be in a subcategory of the category the user would like to link. Also, some people will have deactivated the new image viewer entirely, preferring the default MediaWiki file pages.

More fundamentally, I believe it is bad data model design to put two separate pieces of information into the same value – this makes for an awkward user experience when trying to change just the image or just the category. I understand wanting to tag both a category and an image at the same time, but it would be easy to define separate keys for these purposes (and we pretty much already have that if image=* is used for the image). --Tordanik 16:34, 8 November 2019 (UTC)

> It's not true that applications supporting wikimedia_commons=* automatically work with this new syntax

You're right, it's not 100% true.

> The proposed syntax is quite hard to remember or write by hand

I agree: see my comment 09:07, 7 November 2019 (UTC).

>I suspect many or even most people instead come from a Wikipedia page, or the image may be in a subcategory of the category the user would like to link.

I checked image=* values. The prefix could be "wikipedia article", "wikidata item", even "wikimedia file".

> More fundamentally, I believe it is bad data model design to put two separate pieces of information into the same value.

Yes. Unfortunately, this is the case of wikimedia_commons=*. It could contain one image or one category.

> we pretty much already have that if image=* is used for the image

Curently, most? applications don't handle correctly image=File:xxxxx.jpg.

Especially OSM website that don't display links for theses values.

• But it could change

Cleanup of image=* tag that links to commons

I created this suggestion for cleanup of key:image, see Automated_edits/pangoSE#Key:image.--PangoSE (talk) 11:57, 23 January 2020 (UTC)

what do people thing about splitting wikimedia _commons into "wikimedia _commons:category" and "wikimedia _commons:file".

The main reason I suggest this is that it would clue users into not putting the whole Wikimedia URL in the tag field. Additionally, it would make it easier to quarry if, say, you wanted only wanted to search for "file:" and not "category:" potently making the query faster. But this is a more side effect, I mostly want to remove ambiguity in the tag name.

"it would clue users into not putting the whole Wikimedia URL in the tag field" why it would help with that? And if there is larger scale issue with that then it is relatively easy to fix with bot edit Mateusz Konieczny (talk) 08:02, 26 September 2023 (UTC)

Currently, users who use iD, can get prompted to add the wikipedia_commons tag when clicking “add field”. It seems that users are just adding the full commons URL without reading the wiki. I propose splitting Wikimedia _commons into two new tags, “wikimedia _commons:category” and “wikimedia_commons:file”. The new tags would be specifying that you need the “file:” or the “category:” portion of the URL. “It's in the name” so to speak. Additionally, this might solve some of the issues that were discussed on a forum post that I found after making this post. https://community.openstreetmap.org/t/restrict-wikimedia-commons-urls-as-image-tag-values/2271.
As for bot editing, I'm not familiar with it nor have I made any automated edits, so I'm uncomfortable with using them. Necessarycoot72 (talk) 09:17, 26 September 2023 (UTC)

Why you think that name change of tag, not visible to iD users, would cause them to stop putting link into this field? For bot edits - this is relatively simple to perform and vastly lower effort than migrate to different tags all the people adding and using this tag. If someone else will propose such mass edit and community will clearly accept it (migrating say https://taginfo.openstreetmap.org/tags/?key=wikimedia_commons&value=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FCategory%3ABurgerweeshuis_%28Middelburg%29#overview to wikimedia_commons=Category:Burgerweeshuis (Middelburg) I can run it, but note that it is less than 86 objects. You can fix it even manually at vastly lower effort than deprecating this key (you can find cases by going to https://taginfo.openstreetmap.org/keys/wikimedia_commons#values and searching http in values, then using overpass turbo or level0 links for each value) Mateusz Konieczny (talk) 13:58, 28 September 2023 (UTC)

Support for galleries

Could be used Commons gallery as on 503134835 503134835 for wikimedia_commons=Acueducto de Segovia? Davileci (talk) 00:52, 22 May 2024 (UTC)

Categoriesgalleries are almost always poorly maintained and/or abandoned on Commons (as they rely on manual upkeep) so I would not encourage linking them Mateusz Konieczny (talk) 17:02, 24 May 2024 (UTC)

I would argue with that. It's galleries that are poorly maintained and/or abandoned. Categories, even though they are populated and maintained manually, are the primary tool for structuring info at Commons. Yelisey90 (talk) 22:31, 29 May 2024 (UTC)

oh no! I meant to complain about galleries and recommend not using them! Fixed (with strike-through for old content). Sorry for inverting meaning! @Davileci: @Yelisey90: Mateusz Konieczny (talk) 15:25, 30 May 2024 (UTC)

Allowed photos policy paragraph

I'm not really happy with this edit, I think it's too prominent and could discourage someone from contributing to Wikimedia Commons, also I do not think that such policy applies to OpenStreetMap related images.

This part already referenced the scope but in the opposite way, encouraging users to contribute.

I personally followed Commons images used on OSM via UsageBot for 1-2 years and I don't ever recall an image deleted by Commons because of that policy, but always because of low quality, copyright violation ecc.

regarding point 2 and 3: pictures used on OSM always document a geographical physical element in a certain moment in time, so they always bring something new respect existing photos (it's not like someone uploaded a higher quality scan of the same book)

For these reasons I don't find it correct to put a "Note that the Commons Project scope policy poses some problems" as the first thing someones reads when in reality this policy has never (again, in my experience) been a problem for mappers images. Thoughts? --Ivanbranco (talk) 10:10, 11 September 2024 (UTC)

The Commons discussion is explicit that contributions are to be encouraged. Thanks a lot for the diff link, and thanks a lot to Mateusz Konieczny for opening the discussion at Commons and adding the results here. What about this, to move the link and quotes out of the image desc, feel free to move without notice, wherever they can be reasonably found --Opk12 (talk) 21:11, 11 September 2024 (UTC)

What to link?

I've always thought we should use wikimedia_commons=* to link files that depict the element, but this is not explicitly stated in the wiki at the moment.

For example:

1. This building links to a Welsh poetry book (link). I would have expected a picture of the building instead.
2. This meadow used to link to a video in which a person explained the meadow's name pronunciation (link). Again, I would have expected a picture of the meadow.
3. This building used to link to an image of a men and a horse, again, I would have expected a picture of the building (link).
4. This building used to link to an image of a receipt (link).

Personally I would like to suggest in the wiki that the linked file should depict the element.

Other cases I would like to discuss:

1. This house (and many other nearby) links to a video-talk with a local. I would have expected a picture of the building.

If the file is being used as a source instead, wouldn’t it make more sense to use the changeset source field or the source=* tag?

To conclude, should we restrict the range of linkable files, encouraging only files that depict the element itself, or should users feel free to link anything they find relevant?

Thoughts?