search

gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.51k stars 811 forks source link

Render memorial=stolperstein #4891

Open c-h-r-i-s-t-i-a-n opened 8 months ago

c-h-r-i-s-t-i-a-n commented 8 months ago

Expected behavior

In the last years there has been a massive increase in usage of memorial=stolperstein (vs. memorial:type=stolperstein). Actual usage count is 15 K.

So I suggest the rending of these objects in Z18+ with a special icon.

Actual behavior

For now, Stolpersteine are rendered with the generic historic=memorial icon.

imagico commented 8 months ago

This is a very old matter with a very long history - relevant links are:

1066

3356

https://community.openstreetmap.org/t/stolpersteine-tagging-scheme-problem/84268

Attempt at a summary:

For a long time these have been consistently mapped with memorial:type=stolperstein (10k instances by 2014, 20k in 2018) and memorial=stolperstein was a fringe tagging with less than 100 uses until 2018. Then some people started an organized push to change established tagging (despite the German community being mostly not in support of that), rewriting the wiki to frame memorial:type=stolperstein as discouraged and memorial=stolperstein as the new and better thing. And with support from the iD developers and a (from what i can see undiscussed) mechanical edit in June this year this tagging is now at 14.5k uses - compared to still 22k for memorial:type=stolperstein. If the mechanical edit was reverted it would be 10k vs. 26.5k.

Back in 2016 the main argument against dedicated rendering of memorial:type=stolperstein was that it is highly specialized tagging deliberately designed to be non-generic (unlike memorial=plaque) and that it is therefore questionable to introduce dedicated rendering for it here. However, since then we have introduced dedicated rendering for memorial=plaque - and it would IMO be no problem to render these the same way as memorial=plaque - like we do for memorial=blue_plaque already - which is similarly specialized.

But unfortunately the tagging of these now needs to be considered disputed and there does not seem to be consensus support for either of the taggings mentioned any more. Because of that and because our mission is to support consistent tagging practice and not to push for tagging concepts without consensus support in one direction or the other, unfortunately right now i would be against rendering this in any tagging variant.