Openstreetmap-website: Display a link for wikimedia_commons keys

Created on 25 Jun 2019  Â·  23Comments  Â·  Source: openstreetmap/openstreetmap-website

I'm often using wikimedia_commons as an alternative to the source tag.

As an example, I had discovered this image, but didn't know the exact position of the wheel. 2 weeks later I notice someone mapping it with an incorrect name and then correct/complement his edits and link to the image as proof.

Right-clicking on an wikimedia_commons tag in JOSM will show an option to open the image in a browser (which I find really usefull) and Overpass Turbo will show links with this tag, but of course far from everyone are familiar with these options, so I'm thinking an option to just click a link on the website would be really nice.

Most helpful comment

I've rebased the branch from my pull request #834 which implements this today on the current master branch, and it still seems to work.

All 23 comments

There are only about 16000 such tags in the entire OSM database. I'm really not sure that rises to the level of deserving special case treatment in the user interface.

Well, I was hoping :-). I am aware that I'm a fairly advanced mapper in this respect and that the majority of the ~1000 tags in Denmark alone were added by me, but I am starting to see other mappers add these tags too and the tags on this tram museum (added a few days ago) really appears to have sparked another mappers interest, so I thought it might be time to have a go at it.

key image show link (for URL only, not for Wikimedia Commons filenames or groups).

Adding a link to all "pictures" tags will help new (and experimented) users to check the value, see easily and quickly the picture itself.

See also #986, Photo linking on the wiki.

Implemented in 2014 in not yet reviewed, merged or rejected #834

OpenStreetBrowser manages to display Wikimedia Commons filenames https://www.openstreetbrowser.org/

+1

Would love to see this on the openstreetmap.org-Website

I've rebased the branch from my pull request #834 which implements this today on the current master branch, and it still seems to work.

See also #2405

@tomhughes It's not a problem of quantity, but quality 😉

More, if OSM website display a link for wikipedia and wikidata, why it can't display a link for wikimedia_commons ?

Also the number grow every month 18 739 in november vs 16000 in june.

See w62280106

Because wikimedia_commons are not linked, OSM contributors add a redondant image with a long and human unreadable URL:

See n3240845997, n3774387852

@pyrog is right: if we want to keep the database tidy, we should remove the image tag (Edit: @pyrog, when the wikimedia_commons is present and presenting the same info, due to the context it was obvious... to me).
But as long as normal contributors won't see that wikimedia_commons refer to an image or want to be able to see the images they will add the duplicate again and again... something @mstock commented on 15 Nov 2014 in his PR... The 5-year anniversary is nearing! :birthday:

@Bibi56 I don't want to remove image tag 😉
It is useful for pictures on other web site than wikimedia, mapillary…

But yes, if image contain link to wikimedia, flickr, mapillary… I suggest to use the appropriate tag 😄

I think the right logic to apply is not "OSM already displays links for X and Y so why not also display links for Z" but "the constant addition of new link targets shows that this is unmaintainable, so let us stop showing any links", and remove those we already have. This will also stop the nonsense link addition mentioned by @pyrog.

so let us stop showing any links

No links is clearer than some links 😉

the constant addition of new link targets shows that this is unmaintainable

In one hand, maintenance of software is difficult…
In the other hand, maintenance of the database is more difficult.

Yes, adding links to the software is difficult, but…

  • contributors could send PR
  • software could use a repository of pairs of regex/url to avoid rewriting the code each time a new link is needed
  • this repository could be shared by several project (i.e. OSM, Overpass-Turbo, JOSM, Osmose, Map of historical objects…)
  • new links are not needed every days 😉

This will also stop the nonsense link addition

Adding link have sense.

Again, it:

  • lower the maintenance of OSM database
  • help contributors and users to understand keys
  • help to find POI on the field (i.e. fire hydrant)
  • help to check mapping…

PS: Adding link could be discussed/voted by the community.

My primary reason for adding wikimedia_commons links is that they help build confidence in our data (well, at least I often feel more confident in our data, when i can easily find images showing the objects represented in our data). I think makíng it easier to show other mappers what some data object is supposed to represent, actually helps OSM.

I think the right logic to apply is _not_ "OSM already displays links for X and Y so why not also display links for Z" but "the constant addition of new link targets shows that this is unmaintainable, so let us stop showing _any_ links", and remove those we already have.

@woodpeck , please have a look at a possible solution mentioned in #2405: that _would_ be a nightmare if it wasn't already maintained by others.

Pointing at a table in wikidata is not a "solution" at least not until somebody writes a pile of code to do something with it... History tells me not to rely on such things anyway as they invariably go away or change their API so every time you try and refresh from them you wind up having to rewrite the code that pulls from them.

Right, not fully maintenance free. But to be on the safe side you can store the result so when the automatic update would fail you could still use old format until it's updated.
Anyway the table can be saved as JSON or CSV and maintained locally if updating the mechanism is too work-intensive.

On the other hand, using a curated list (mentioning OSM tags) can help preserving the used format/data.

I really think it's a red herring - it's a table with a dozen or so entries and it doesn't really save anything over just hand coding the ones we want.

The real problem is that it outsources the decision about what we will or won't link to to a third party which I don't think is appropriate.

At the end of the day you can all talk as much as you want here but regardless of anything else nothing it going to happen until somebody steps up to write some code.

nothing it going to happen until somebody steps up to write some code.

@tomhughes, when I see a 5-years old PR solving this request I doubt the main issue is writing the code.

The real problem is that it outsources the decision about what we will or won't link to to a third party which I don't think is appropriate.

Here it's delegated to code maintainers. Is it better or worse than a community decision?

Please note that the table takes into account the fact that a tag exists in OpenStreetMap and tags creation under OpenStreetMap is a community decision made by OpenStreetMap contributors.

If you prefer a manual update just export the request in CSV or JSON and re-sync the file from time to time.

I'm not sure what the history of that PR is to be honest. I don't remember it and I don't appear to have looked at it for some reason. Most likely it came in at a time when I wasn't able to look at it and then it got forgotten about.

That said this has always been a controversial area because the more of these you add the more people will want and we probably want some sort of policy to avoid having to maintain code to add links for every obscure tag that could be linked.

Closed by merging #834.

@Bibi56 I don't want to remove image tag
It is useful for pictures on other web site than wikimedia, mapillary…

But yes, if image contain link to wikimedia, flickr, mapillary… I suggest to use the appropriate tag

See https://wiki.openstreetmap.org/wiki/Automated_edits/pangoSE#Key:image for a suggestion to clean this up. There are >80,000 image= tags with links to wikimedia commons where 50,000 of them is in Germany alone.

@pangoSE, yes we are on the same page.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pangoSE picture pangoSE  Â·  7Comments

dog1993 picture dog1993  Â·  8Comments

Zverik picture Zverik  Â·  3Comments

HolgerJeromin picture HolgerJeromin  Â·  5Comments

kgreenek picture kgreenek  Â·  6Comments