Render images on feature page

[pangoSE]

I suggest we implement rendering of images on feature pages below the list of tags. If a feature has both image= and wikimedia_commons= and mapillary= tags we could either render all or just one of them. To avoid rendering multiple images we could decide here about which would be preferred.

[eehpcm]

The Historical Objects map already does something like this (but only if the image is attached to a historic/heritage object). Example.

The query tool of standard carto already does give a working, clickable link to a wikimedia_commons object if one has been specified. Excample. So it ought not to be too hard to make it display the image instead. Whether or not that is considered desirable by a majority is another matter.

[pyrog]

Tags order could be (see Historical Objects map):

1. wikimedia_commons
2. wikidata (could get images from property P18)
3. mapillary
4. image

[dieterdreist]

sent from a phone

On 26. Aug 2020, at 10:33, Yves Pratter notifications@github.com wrote:

wikimedia_commons wikidata (could get images from property P18) mapillary image

this seems reversed, my suggestion for order: image wikimedia_commons (wikidata wikipedia )

definitely no mapillary integration (facebook)

I guess these should be opt in or load only after pressing a button.

[pyrog]

this seems reversed

I put wikimedia_commons first because usually it link to quality pictures and values are better formatted (but of course should be discussed and tested 😃). image is a bit "holdall" (contain full URL images, Wikimedia values, Wikimedia URLs, Mapillary values, Mapillary URLs…) A lot of software don't managed correctly all variants.

definitely no mapillary integration (facebook)

I understand (and I'am not happy with GAFAM) but mapillary tag is used, sometime this is the only one. So IMHO it must be kept. I don't prefer it because usually it link to bad quality pictures (blurred…)

Multi-values

All theses tags could contain more than one image separated by ;

[woodpeck]

I am uncomfortable with this idea. The openstreetmap web site is not intended to be a business directory or a browsing catalogue for features. A "node/xxxx" or "way/xxxx" page is not a "feature page", its primary purpose is not to describe or illustrate the real-world "feature". The page is there if you want to look at how something is tagged in OSM and who made the change. It's an internal debugging tool for the mapping and quality assurance process, not a public-facing page. Changes like this will ultimately lead to a restaurant having "a yelp page", "a facebook page", and "an openstreetmap page". Restaurant owners will try to ensure that OSM has the prettiest picture of their restaurant (instead of the one most useful for mapping). In my opinion, this is not something we should be doing.

[pyrog]

The openstreetmap web site is not intended to be a business directory or a browsing catalogue for features

Ok, I'am agree to do not show pictures in an object page 😃 A lot of website are dedicated to display defibrillators, fountains…

But for "internal debugging", I think that links to images, references… should be displayed (cf. Tag2Link).

Also please note that usages of pictures are:

• help understand how objects were mapped
• help "decipher" aerial images
• "proof" that an object exist on the field

[pyrog]

Also, I think that the community should work on writing libraries in several languages (javascript, python, ruby…) to handle correctly tags (multi) values that link to something on the internet.

See PR#2621

It will help OSM developers to spend time on more useful task and database to be cleaner and more consistent.