Closed tilmanb closed 7 years ago
Unfortunately memorial:type is not available in the database (see https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style), so it can not be easily done.
EDIT: memorial tag is also not available.
Unfortunately memorial:type is not available in the database (see https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style), so it can not be easily done.
Also unfortunate is, that there are two tagging schemes. It is the classic discussion that seems to come up each time refinement of a tag is needed by a "type" specification: use the A:type=x namespace or simply use A=x instead...
The historic=memorial Wiki page warns against using memorial:type=x, and use memorial=x instead. However, the "memorial:type" Wiki page is better layed out than just "memorial", and in practice, TagInfo shows memorial:type to be more often used:
http://wiki.openstreetmap.org/wiki/Tag:historic%3Dmemorial http://wiki.openstreetmap.org/wiki/Key:memorial:type http://wiki.openstreetmap.org/wiki/Key:memorial
Also see the Talk page, which is inconclusive about this distinction: http://wiki.openstreetmap.org/wiki/Talk:Tag:historic%3Dmemorial
try tags ? 'memorial' and tags->'memorial:type' because all tags should be in the database (if tags are importetd).
2014-10-16 17:03 GMT+02:00 wambacher notifications@github.com:
try tags ? 'memorial' and tags->'memorial:type' because all tags should be in the database (if tags are importetd).
no, there are no hstore columns in the carto style db for the mapnik style (english). I think you are confusing this with the German style (mapnik:de).
👎 to memorial:type=stolperstein. The usage of it is too country-specific. I'd be more open to memorial=plaque along with the other memorial
subkeys, but usage isn't great.
sent from a phone
On 15 Dec 2016, at 06:35, Paul Norman notifications@github.com wrote:
👎 to memorial:type=stolperstein. The usage of it is too country-specific. I'd be more open to memorial=plaque along with the other memorial subkeys, but usage isn't great.
although this had started in Germany as a project by a German artist, there are now occurrences in other countries as well. As long as there are many, why does it matter those are not equally distributed?
We aim to support generic tagging. memorial:type=stolperstein
on the other hand is highly specialized. If memorial=plaque
(3617 uses) and memorial:type=plaque
(476 uses) are rendered this could be considered but otherwise it would support incorrect tagging.
Note the fact that we have competing memorial=*
and memorial:type=*
is in itself an issue.
The usage of it is too country-specific.
There are stolpersteinen in 18 different countries now.
However, I agree usage is too specialized. Not too mention that there are Stolpersteinen every couple of houses in some German cities.
2016-12-15 9:27 GMT+01:00 Christoph Hormann notifications@github.com:
We aim to support generic tagging. memorial:type=stolperstein on the other hand is highly specialized. If memorial=plaque (3617 uses) and memorial:type=plaque(476 uses) are rendered this could be considered but otherwise it would support incorrect tagging.
I understand the wish to support generic tagging, but aren't we also aiming to support actual tagging rather than imposing how people should map? Of all memorial:type tags, 84% have the value "stolperstein" (17900), while 4% have the value "plate". By rendering the latter and not the former we would try make people map differently than how they do, hence abusing the power that comes with deciding on what gets rendered on the "main" map style.
Even looking at "memorial" and "memorial:type" together the value "stolperstein" is almost 50% of all values, followed by "war_memorial" with just 16,7%.
"Supporting" this particular memorial:type / memorial value does not mean we would have to render them more prominently, on the contrary it would mean to not show them on middle and lower high-zoom level, and only show them on z19 (for example, or z18 and 19), thereby decluttering the map on z16 and 17.
Note the fact that we have competing memorial= and memorial:type= is in itself an issue.
there are more competing tagging styles in the db, but it's our task to deal with it, not to uniform the tagging (although not supporting neither certainly has contributed to both evolving parallely).
2016-12-15 9:53 GMT+01:00 Matthijs Melissen notifications@github.com:
Not too mention that there are Stolpersteinen every couple of houses in some German cities.
that's actually the reason for this ticket: it asks to render them less prominently / only on very high zoom levels. IMHO closing this ticket was premature.
You're right, I didn't read well.
memorial:type=stolperstein on the other hand is highly specialized
Yes, and I'd like to avoid using it for that reason, even if it's to exclude rendering instead of rendering a specific feature.
I'd be fine with adjusting rendering based on memorial=plaque, although the usage might not be there.
2016-12-15 10:49 GMT+01:00 Paul Norman notifications@github.com:
I'd be fine with adjusting rendering based on memorial=plaque
what has this to do with this issue? Are you suggesting people should change tagging from memorial:type=stolperstein to memorial=plaque? Why do you favor the "memorial" key if the "memorial:type" key is used more often?
what has this to do with this issue? Are you suggesting people should change tagging from memorial:type=stolperstein to memorial=plaque? Why do you favor the "memorial" key if the "memorial:type" key is used more often?
The memorial
key is mentioned earlier in this issue, and is much more widely used.
what do you base this on? I'm relying on taginfo and the current relation is 45% "memorial" vs. 55% memorial:type.
Can you please answer the question whether you are suggesting people should change tagging from memorial:type=stolperstein to memorial=plaque in order to account for it in the rendering? Thank you.
This ticket is exactly what I'd like to do with plates - render them only on z19 and using smaller and more appropriate icon. It's about making them less visible than standard and this memorial type fits this conception perfectly.
I am surprised to see that the Stolperstein plaques were not handled in #2689.
Did i missed a discussion about that?
Should we communicate (tagging ML, Wiki) that a stolperstein should have
historic=memorial
memorial:type=stolperstein
plus a "new" memorial=plaque
.
The better rendering for that would promote this additional tag.
This would be a good thing IMO as this would reduce special casing for all osm data consumers.
I'm not sure what's the right way to deal with it, so I took a conservative approach. Stolperstein and blue_plaque are similar cases, so it should be good to unify their tagging somehow.
Until some progress or discussion about tagging these types will occur, I think we should close this issue.
There are lots[0] of "Stolpersteine"[1] in the OSM data. Each Stolperstein is a memorial for one or more persons deported and killed by the nazi regime.
The number of Stolpersteine is huge, and they someplace[2] clutter the map output at z18.
This has lead to users deleting them "for simplicity's sake" and to "clean up the map". This is unacceptable, of course, but the problem of map clutter remains.
So i propose to render features tagged with
only at z19.
[0] 12567 nodes as of this writing, see http://taginfo.openstreetmap.org/tags/memorial%3Atype=stolperstein [1] https://en.wikipedia.org/wiki/Stolperstein [2] http://www.openstreetmap.org/#map=18/50.12166/8.68692