Stolpersteine tagging scheme problem

Hi,

We’re currently discussing special rendering of memorials on OSM Carto and Stolpersteine looks like a problematic case, because all other types seem to embrace memorial=* notation, while Stolpersteine are usually using memorial:type=* notation.

Look at the usage numbers:

https://github.com/gravitystorm/openstreetmap-carto/pull/3356#issuecomment-414965872

and notation trends:

https://github.com/gravitystorm/openstreetmap-carto/pull/3356#issuecomment-414982577
https://github.com/gravitystorm/openstreetmap-carto/pull/3356#issuecomment-414734646

The memorial:type=* notation is documented here:

https://wiki.openstreetmap.org/wiki/DE:Stolpersteine

Since this is local German community decision and this subforum is very active, I’d like to ask here what do you think about changing this scheme (automated tag scheme migration + manual documentation update), to conform with global scheme used by mappers?

I see two possible solutions, both with some ups and downs:

  1. move it to historic=memorial + memorial=stolperstein

  2. move it to historic=memorial + memorial=plaque + plaque=stolperstein

  3. is shorter, but keeps special local type as the first class member, 2) would work out of the box, without any other code changes, and blends with global categories, but is nested more than usual.

I’d like to hear any comments from you, I hope we can find sane solution.

Hi,
is there a problem with memorial:type (beside of not being “standard”)?

If it comes to Umtagging my vote goes for
historic=memorial + memorial=stolperstein

1 Like

hallo,

ich würde 2) move it to historic=memorial + memorial=plaque + plaque=stolpersteine bevorzugen.

Schön das sich auf OSM Carto in Bezug auf die Darstellung von Denkmälern etwas tut…

Grüße von Lutz

+1

1 Like

I support 1) move it to historic=memorial + memorial=stolpersteine

1 Like

I would also be in favor for historic=memorial + memorial=stolperstein. Keep it simple :slight_smile:

Thanks for your voices. This forum is more active than I even thought of and soon this thread would be rolled out to the next page, faster than I expected. Currently proposition 1) gained your support and that’s OK for me, but I would be happy to hear some more comments just to be sure before we proceed further.

@chris66: there’s nothing fundamentally wrong with memorial:type and in OSM you could officially use any tag you like. However we have more and more problems as data consumers (rendering is kind of it) with multiple possible schemes and lack of consistency. That was a problem with castle/manor, which was confusing and made it harder than expected.

I have been looking into the Stolpersteine project. Stolpersteine are not just plaques, though they carry a plaque.

Therefore I am in favour of tagging the objects as historic=memorial + memorial=Stolperstein. Including the leading capital, because it is a fixed german name for these art objects.

For Nederland, only a few Stolpersteine have been mapped. I would like to map&tag them all in one go. There is no central database., but there are lists, all different and incomplete but still better than nothing.

Extra tags? Names, addresses, inscriptions, stories and media are recorded elsewhere and the .eu site plans to put everything on their site. Might be better to include a link to that, if available. Same for wikidata, and wikimedia. Why duplicate what’s already available, unless we can really improve it.

Edit:
in short: Retag to scheme 1, +1

-1
sowohl memorial:type als auch memorial sind beide derzeit als stolperstein (kleines s) gemappt.
Auch steht es im Wiki in klein.

Soll bei der Gelegenheit auch der name korrigiert werden? Nicht der Stein hat ja den Namen sondern die Person an die erinnert wird.

Also name → person:name

English translation on GitHub

Hallo,

ich bin von der Änderung nicht überzeugt. Es scheint mir, dass das Aufräumen des Taggings die einzige Motivation für diese Änderung ist und die unbeschränkte Macht des Kartenstils OSM Carto, das Tagging in jegliche gewünschte Richtung zu lenken, den Befürwortern dieser Änderung begrüßt wird. Es ist bekannt, dass Mapper für den Renderer mappen, auch wenn sie es nicht tun wollen. Die Nutzung eines bestimmten Tags durch OSM Carto beeinflusst die Entscheidung, welches Tag zu verwenden ist, erheblich. Ich erwarte von den Maintainern des Kartenstils, neutral zu sein und nicht die Tagginggewohnheiten in eine bestimmte Richtung zu lenken.

Beide Tags sind in der Spalte “tags” (vom Typ hstore) in der Renderingdatenbank. Die SQL-Abfragen von OSM Carto sind jetzt schon voll von CASE WHEN … THEN … ELSE … END. Auf eine parallele Unterstützung zweier Taggingvarianten kommt es jetzt auch nicht mehr an.

Die zwei Keys “memorial” und “memorial:type” scheinen keine Unterschiede in der Bedeutung zu haben. Das Argument, dass es die Auswertung für Entwickler vereinfache, ist in diesem Fall ein schwaches.

Das Bevorzugen eines Keys gegenüber eines anderen macht die Daten nicht besser. Es wird nur einen Effekt haben: Mapper werden fast alle Stolpersteine in Deutschland bearbeiten und dabei den last_modified-Zeitstempel aktualisieren. Die Objekte sehen dann aus, als wären sie frisch geprüft worden, aber in Wirklichkeit sind sie nicht vor Ort kontrolliert worden (die meisten stecken noch so im Bürgersteig, wie sie hineingesteckt wurden, aber manche sind bei Bauarbeiten entfernt oder verlegt worden).

Viele Grüße

Michel

I would also be in favor for historic=memorial + memorial=stolperstein. I am happy to see that those Stolpersteine are finally about to be rendered differently on the default stylesheet.:slight_smile:


Nakaner, das offensichtliche Fazit dass man aus dieser Erkenntnis ziehen kann, ist, dass der last_modified-Zeitstempel eben nur bedingt als zuletzt-geprüft-Zeitstempel interpretierbar ist. Um speziell das auszudrücken gibt es entsprechende Tags wie survey:date oder checkdate. (Oder Alternativ die History des Objektes durchkämmen und nach dem letzten Changeset mit source=survey suchen, das ist mit der Api 0.6 aber nicht praktikabel)

Ich möchte hier Nakaner deutlich zustimmen, es geht hier primär um die Frage der angemessenen Zurückhaltung der Stilentwicklung hinsichtlich der Konsensfindung unter Mappern bezüglich Tagging. Insbesondere die implizierte Erpressung nach dem Schema: Wenn Ihr möchtet, dass das gerendert wird müsst Ihr euer (für sich genommen erst mal konsistentes) Tagging so ändern, dass es uns besser in den Kram passt halte ich für höchst unangemessen.

Wer jetzt in diesem Fall etwas opportunistisch sagt: Das anders zu taggen ist ja gar keine so schlechte Idee also tun wir den Leuten doch den Gefallen, der sollte sich klar machen, dass es das nächste Mal eventuell was anderes ist, wo man als Mapper deutlich anders zu steht. Ich möchte da vor allem an einen ähnlichen und deutlich bedeutenderen Versuch von Anfang des Jahres erinnern:

https://lists.openstreetmap.org/pipermail/tagging/2018-March/thread.html#35347

In der Vergangenheit war die Stilentwicklung meist sehr zurückhaltend hinsichtlich solcher Einflussnahmen und dies wurde über die Jahre auch immer wieder in der Praxis bekräftigt, insbesondere hinsichtlich des Prinzips, dass es nicht Aufgabe des Stils ist, auf eine systematischere Key-Semantik hinzuwirken (sprich: Tags nicht zu rendern, weil sie nach irgendeiner Überzeugung den falschen Key verwenden) oder bestimmte Tagging-Ideen nach subjektiven Präferenzen (wichtig vs. unwichtig, bequem oder unbequem für den Stil-Entwickler) und ungeachtet objektiver Kriterien wie Überprüfbarkeit und konsistente Anwendung durch die Mapper entweder zu pushen oder zu unterdrücken.

Es gibt aber keinen Zwang für OSM-Carto-Maintainer, sich an diese Grundsätze zu halten. Folglich obliegt es letztendlich der OSM-Community, darüber zu wachen und im Zweifelsfall der Stilentwicklung klare Grenzen aufzuzeigen.

Die Frage, die Ihr euch hier also stellen solltet, ist nicht welches Tagging ihr grundsätzlich besser fändet, sondern ob Ihr die Vorgehensweise unterstützt, die hier praktiziert wird, nämlich von Seite der Stilentwicklung aus zu versuchen, eine etablierte und konsistente Tagging-Praxis zu ändern.

Automatic translation is not too clear for me, so I will just base on English text from Nakaner and some guessing.

I am perfectly able to understand why proposition of change could raise alert. But I find some strong assumptions here, that work purely out of fear, and are unfair.

  1. All the Stolperstein are rendered and will be rendered, so no threat of disappearing is included.
  2. In the worst case they would be rendered as they are.
  3. While enhancing overall memorial rendering we could improve their rendering too, to make them less obvious, according to their size.
  4. I asked the community about how to do it and there were no other propositions.
  5. Why standard style development should be worse and more cautious than any other sources to show tagging problems, is beyond me.
  6. If two schemes have the same meaning, what is the goal of keeping two of them for one idea?
  7. “I’d like to ask here what do you think about changing this scheme” is as open question as it gets. What’s your proposition to make it less “threatening”?
  8. In the past there was enough of simple tagging cases (mainly “add/remove”), now there’s a need among people to move on to some less obvious cases (mainly multiple tagging schemes).

Die hier geforderte Neutralität würde ich mir von einigen deutschen kommerziellen OSM verwurstern wünschen, in Bezug auf Relevanzfragen. Dort ist der eine oder andere Federführend, und durch gut organisierte Lobbyisten Meinungsbildner.
Grüße von Lutz

Having two tagging schemes for one purpose has little merit. Since the alternatives have no impact on the actual rendering result, that’s no issue.

Fitting in with general usage is an advantage. Simplicity is an advantage. No information is lost or altered by any of the proposed schemes. Retagging is not a problem in this case.

Agree with kocio, especially point 5 and 6.

In my own words, any attempt to actually use the OSM data (in this case, memorial type) is an opportunity, not a threat, to realitycheck if a tagging scheme is sound and whether it could be straightened up, by removing duplicate tagging methods, in this case.

There will always be some reason/occasion for a push to discuss a tagging scheme, some driven by an attempt to map something specific, some by an attempt to actually use the data.

I can follow imagico’s line of argumentation, but I do not share his fear for this case: kocio-pl did not create facts but analysed the situation and put it to discussion, I find both his motivation to straighten up the tagging scheme and his method very commendable.
Also, the actual topic at hand is not exactly controversial (as can also be seen by the comments so far), it is a simple case of two synonymous taggings of which one could be removed, that’s it.
Let’s all be happy that someone is actually tackling this. :slight_smile:

Please don’t make assumptions on my motivation for arguing the way i do - this is frankly both arrogant and demeaning and it demonstrates a lack of willingness to deal with the arguments in substance and instead deflecting by speculating about my motives.

Als neulich Frederik Ramm mehr Rücksicht auf die Belange der Renderer gefordert hat, kam da kein Widerspruch. Ich zitiere unten mal ein wenig. Vielleicht sollte sich die OSM Boheme erstmal einig werden, sonst wird mir vor lauter Richtungswechseln ganz schwindlig.

Edit: Achja, I really appreciate that the maintainer of a rendering style discuss it with the parties concerned. It should happen more often. However, with this experience in mind I doubt he will do it again.

You’re right, speculations about motives are not necessary, sorry. But using words like “arrogant” works the same for me - and you’re not even dealing with arguments, which is what I’d like to hear instead.