Stolpersteine tagging scheme problem

Ich bin voll dafür dass man die Gelegenheit (Standard-Stil möchte memorial nach dem SubType differenzieren) nutzen sollte, die deutsche Sonderlocke zu eliminieren. :stuck_out_tongue:

Die Gegenstimmen (zB es wird der Zeitstempel verfälscht) haben mich nicht überzeugt.

Not anymore…

Welcome to the German OSM forum :laughing:

(Edit: Oh, there is a second page, nvm)

Sorry for the English…mein Deutsch ist nicht sehr gut. My goal is to tag all the Stolpersteine in Nederland as simple as possible. I think I will adopt the general usage of the historic tag, even though the German standard usage is slightly different. If there is a different outcome of this discussion, retagging is not much of a problem. But given the trend in the direct reactions, I think I am safe there.

ok. on the one hand you (the maintainers) want to eliminate memorial:type=*. on the other hand you implented tower:type along to man_made=mast :roll_eyes: i can’t see any clear line of such decisions.

and yes, i think memorial:type could easly transferred to memorial (we need no special tag for germany in this case) … but tower:type, too. and no, i wouldn’t accept an answer like “because it was widely in use”.

ps: i don’t want to know what a newbie thinks about the subtype tower:type at man_made=mast…

To be clear: no, I don’t want to eliminate memorial:type=* - this is not what I want as my goal. It’s just one possible solution of having more coherent tag for memorial types.

There are thousands of keys in OSM and there’s no hope to standardize them all. I could blame “any tag you like” rule or be angry at people not trying to see the problem. But I try smaller, local cleaning, because it is perfectly possible. I don’t believe in a broader scope of cleaning - it will stop in a big discussion IMO. And I don’t want more discussions without the output, I prefer smaller steps, but let they be realistic.

It’s just the easiest way to start - ask people if a tag for a single type of objects could be changed. And it sounds like it’s the solution people agree with.

A newbie will just click the icon in iD probably. And what do you think, how will newbie feel that there is memorial:type mainly for Stolperstein, and memorial for other types? We just have to live with a database people create. Maybe one day the most typical keys and values will be standardized, but until then let’s fix what is possible to fix.

I’ve started tagging Stolpersteine in Nederland, following an online list of gravestones of type stolperstein

Some have already been mapped, sometimes in the memorial=stolperstein notation, sometimes the memorial:type way. Some have name=, some have memorial:text=, some have memorial:addr and some have image=

In these cases I just add memorial=stolperstein.

another problem is, that we don’t know (*) who already use memorial:type … in my view, anyone who uses keys is responsible for checking that the keys still exists

(*) you could invite projects to this discussion, which use memorial:type.

Sorry, I don’t fully understand what did you try to propose?

It might be good to welcome projects, but Tagging is the place where we discuss tagging. Otherwise discussion would never end - see my comment about rendering discussion:

https://forum.openstreetmap.org/viewtopic.php?pid=713157#p713157

OSM is decentralized ecosystem and what I want is more effective ways of making decisions. Constant asking everywhere is just backing up your decisions, not a tool to do things. We need some hubs for this. When talking about rendering, come to the OSM Carto issue trackers. When talking about tagging, we go to the Tagging list. There are still no guarantees that someone will not make a decision that will affect you - it’s the core rule of decentralized projects like OSM is now.

carto want to switch from memorial:type to memorial … that’s fine … but what is with all the other small projects which use memorial:type and don’t read the tagging mailing list or other community channels? in this case the only opportunity is tag both memorial and memorial:type (for backwards compatibility)

If they are not interested, they don’t have to, but it’s their responsibility what to do.

These are drawbacks of decentralized ecosystem. If you want other decision making, change the OSM into more centralized structure. There is no easy solution either way.

I have already agreed to that above, but i don’t think it’s that easy! And no, i personally don’t want to have other decision making, but i think you should be aware of what other will think about the “big” carto, if carto just do it (memorial:type>memorial) :wink:

So what do you do in decentralized projects? Did you actually try it? Because I made such attempts and I know there are always limits of what you could do.

That’s what I already did with this issue:

  1. We had some idea on OSM Carto and we could just change rendering, because we have autonomy, but…
  2. I asked German community what they think about idea, but someone thought it’s better to go to Tagging, so…
  3. I went to Tagging list and still it looks promising, but you think it’s not enough…

…do you see the pattern? You don’t need to do anything, but there’s always something you could do and you didn’t.

Did you ever try to make decision by yourself with 3 separate discussions? Is 3 levels deep “OSMception” still too few of them?..

It’s a clear case for me. Thanks 2 all of u for the input. Whatever the outcome of this discussion, I am confident that the new symbol for Stolpersteine will be an improvement over the current tombstone thingy.

Nur so BTW, anyone knows Stolpersteine?

Selbstverständlich ist uns wumpe ob das Ding nun memorial=stolperstein oder memorial:type=stolperstein heißt, wenn beides signifikant gemappt wird, rendern wir eben beides. Persönlich finde ich memorial= auch konsistenter aber das ist Geschmacksache.

Schade daß aus einer einfachen Frage wieder eine Grundsatzdiskussion gemacht wird. Die Fronten verhärten sich automatisch und am Ende setzt sich der Lautstärkste durch (nicht zwingend die Meinungsmehrheit).

Gruß,
Zecke

I don’t see people discussing the merits of the proposed change (memorial=stolperstein seems to be preferred scheme). Discussion if the rendering team is allowed to propose such changes seems to end with warning “be aware that people might not like it” and I’m aware of it, but I think enough care has been taken to discuss it with people interested in tagging schemes.

I think now it’s the time to move on with the change. I guess it should be:

  1. Change the documentation on https://wiki.openstreetmap.org/wiki/DE:Stolpersteine (it’s in German, so I prefer somebody speaking German to touch it)
  2. Make the automated edit of tagged objects according to the https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct (I had no previous experience with that, so if anyone else wants to take care, it would be much easier)

Edit won’t have any impact on rendering, it will improve once https://github.com/gravitystorm/openstreetmap-carto/pull/3356 is merged and deployed with the new OSM Carto version.

What do you think about this plan? Any other ideas or help?

I can’t help with the German documentation either. I can adapt Dutch documentation, where stolpersteine are mentioned. I have raised the issue in the Dutch forum: the only caution was that memorial:type currently has more usage. No-one made a problem of me adding nodes tagged memorial=stolperstein, or with existing stolperstein nodes, adding the more consistent simple tag.

When retagging takes off, I could do it for Nederland if someone tells me how to do automatic replace, after proper discussion.

Wo wir gerade beim Thema sind:
Viele Stolpersteine in meiner Gegend sind neben historic=memorial zusätzlich mit tourism=artwork getaggt. Letzteres passt doch nicht, oder? Als öffentliche Kunst kann ich das nicht einordnen, für mich gehören die Steine eindeutig in den Denkmal-Bereich.

Naja, suche mal nach “Kunstwerk in Kettwig”.

Fändest Du es als Anwender gut, wenn dann neben den 5 “echten” öffentlichen Kunstwerken noch 50 Stolpersteine angezeigt werden?

eher nicht :wink: