Lifecycle-Präfix bei Relationen? (+Hilfebedarf bei overpass-turbo)

Wo sollte idealerweise das Lifecycle-Prefix bei Relationen hin, z. B. das ‘disused:…’? Im zugehörigen Wiki-Beitrag steht dazu nichts.

Ich finde Folgendes logisch:

Jede Relation hat einen Schlüssel ‘type=xyz’ z. B. ‘type=building’. Betrifft der Lifecycle-Wert alles, was die Relation beschreibt, so wäre meines Erachtens hier der beste Platz für das Präfix:

disused:type=xyz

Das gibt es aber bislang nur 443 mal in OSM, wobei Relationen mit Lifecycle-Präfix eh’ recht selten sind.

Betrifft die Lifecycle-Angabe nur eine einzelne Eigenschaft der Relation, so sollte es m. E. nur an diesen Tag. So kann z. B. eine bestehende Fahrradroute demnächst ein neues Symbol bekommen:

type=route
route=bicycle
symbol=weißes Fahrrad
proposed:symbol=rotes Fahrrad

Bisherige Beschreibung bei route-Relationen:

Bei manchen Relationstypen wird ‘type=xyz’ detailliert mit 'xyz=‘* im Beispiel also ‘type=route’ mit ‘route=bicycle’. Im Wiki wird am Rande der Beschreibung von ‘state=*’ empfohlen, das Präfix ‘proposed:…’ vor 'route=’* zu setzen:

type=route
proposed:route=bicycle

'<Lifecycle-Präfix>:route='* gibt es immerhin über 2.000 mal, vor allem bei stillgelegten Eisenbahnlinien.

Auch das klingt logisch. Allerdings haben nicht alle Relationen diese Detailierung des Relationstyps *). Somit kann man nicht generell sagen, dass der Lifecycle-Prafix vor dieses Tag kommt.

Somit ist weitab der zugehörigen Wiki-Seite ein Vorgehen beschrieben, dass sich nicht allgemein anwenden lässt.

) Bei ‘type=route’ haben nahezu 100% aller Relationen ein 'route='. Bei ‘type=building’ haben dagegen nur 20% ein 'building='*. Andere Relationstypen haben sogar 0% (siehe hier).

Andere Lösung:

Beim Spielen mit overpass-turbo sind mir Relationen untergekommen, wo alle Eigenschaften außer ‘type=xyz’ mit dem Lifecycle-Prafix versehen wurden, das kann auch nicht die Lösung sein.

Hilfsbedarf bei overpass-turbo:

Wie oft es die Kombination ‘type=xyz’ und ':xyz='* gibt, weiß ich nicht, das habe ich in overpass-turbo nicht hinbekommen.

Man müsste erst den Wert von 'type=‘* ermitteln, also ‘xyz’ und dann für jeden möglichen Lifecycle-Präfix die Relationen zählen, bei denen es ein ':xyz=’* gibt. Und das so, dass es nicht ins time-out läuft.

Grüße,
Jochen

Das Schlüsselwort “type” gibt die Art der Relation an, da würde ich keine lifecycle-Präfixe anbringen, die gehören an die Featuretags. Du taggst ja auch nicht disused:way= sondern way= bleibt gleich während der feature-tag umgetaggt wird: disused:amenity=museum

“type” ist kein “echter” tag, dass man das überhaupt sehen kann liegt an der Geschichte, wie Relationen zu OSM kamen, und auch daran, dass man sich beliebige Relationen ausdenken können soll.

Stimmt, der Type der Relation ist ja nicht das, was geplant / ungenutzt / abgerissen usw. ist.
Bei ‘type=multypoligon’ wäre diese Lesart schon komisch, ‘multypoligon’ sagt nur dass die Relation ein geometrisches Konstrukt beschreibt, und nichts über deren Eigenschaften.

Anderseits ist das bei ‘type=bridge’ m. E. nicht mehr der Fall, das ist ja fast ‘bridge=yes’, also ein Feature.

Ähnlich wie ‘type’ fühlt sich für mich der Lifecycle-Präfix selber aber auch nicht als “normaler Tag” an, insbesondere bei 'proposed:‘* und 'razed:. Letzteres ist ja fast schon wie die Löschmarkierung an Datenbankeinträgen. Die Diskussion über die Sinnhaftigkeit von 'razed: würde ich hier aber nicht führen wollen.

Mein eigentliches Anliegen ist, eine einfache Regel zu finden, wo das Präfix dran kommt. 'type='* zu nehmen wäre einfach, da es das an allen Relationen gibt. In der Semantik aber wirklich merkwürdig, siehe erster Satz dieses Posts.

Ist es dann wirklich so, dass es kein einheitliches Vorgehen geben kann?

Bei Routen:

type=route
abandoned:route=bicycle

Analog bei network-Relationen und den anderen Relationstypen, wo ‘type=xyz’ mit 'yxz='* untersetzt wird:

type=network
proposed:network=rcn

Bei Brücken (wenn es eigentlich kein Brückentyp bekannt ist):

type=bridge
disused:bridge=yes

Bei Multipoligonen:

type=multipolygion
proposed:landuse=forest

usw.?

Ich bin mir auch nicht sicher, ob es für das Lifecycle-Präfix bei allen Relationstypen sinnvolle Anwendungsfälle gibt.

Für die speziellen Schlüsselwörter “disused” oder “razed” sicher nicht, aber das einfache “was” passt sicher überall.

Würde ich auch so sehen.
Aber allgemein bräuchten wir eine globale Regel, was mit Lifecycle versehen werden soll und was nicht. An einem abgerissenen POI ein “razed:email” klingt schon nicht wirklich richtig.

sage ich ja, feature tags. “email” ist kein Featuretag sondern ein Attribut.

Also, disused würde ich nie mit type=route verknüpfen, das ist aus meiner Sicht absurd, egal, wo man das disused hinpackt. Der was: prefix wäre OK, wenn man evtl. vorhat, das Ding in irgendwas ganz anderes zu ändern. Ob eine Route benutzt wird oder nicht lässt sich ja kaum verifizieren. Ein aufgelöstes Multipolygon lösche ich, macht doch keinen Sinn, das ohne Member stehen zu lassen.

Ach, ich kann mir da schon was vorstellen, z. B. wenn eine Straßenbahnlinie zwar ausgeschildert ist, aber vorrübergehend nicht fährt.

Auch wenn die Wegweiser einer Fahrradroute nicht gepflegt und größtenteils schon verschwunden sind muss man irgendwie taggen, dass diese Route zwar noch nicht ganz weg ist aber größtenteils unnutzbar ist. Wenn jemand wieder Geld in die Hand nimmt kann man das dann wieder rausnehmen.

OK, ÖPNV Relationen habe ich nicht bedacht. Ist es denn relevant, ob die Tram tatsächlich fährt? Wird da nicht service_times=* angewendet? https://wiki.openstreetmap.org/wiki/DE:Key:service_times

Zu Fahhrad/Wanderrouten: Bei einzelnen highway haben wir ein trail_visibility=*. Gibt es entsprechendes für die Beschilderung einer Route?
Ich bin auf dem Rad praktisch immer mit Navi und selbst geplanter Route unterwegs, da brauche ich die Schilder nicht. Aber beim Erstellen der Route hat mein Router evtl. die route=bicycle Relation in seine Kalkulation mit einbezogen, und da wir nur solche Routen mappen (wollen), die ausgeschildert und somit ohne weitere Hilfsmittel zu erkennen sind, ist das halt relevant.

Damit wird eher der Takt oder die Nachtruhe angegeben. Wenn die Linie aber wegen Bauarbeiten länger nicht fährt, ist das m. E. nicht der richtige Tag.

Hab ich noch nicht gesehen. ‘disused:route=bicycle’ ist sicher nicht ideal, denn die Route ist nicht “unbenutzt” sondern deren Beschilderung “unbenutzbar”, da lückenhaft. Aber vielleicht muss man es nicht päpstlicher nehmen als der Papst es tut, es gibt sprachlich ganz andere Verbiegungen in OSM-Tags.

Fazit bisher, es gibt keine einheitliche Lösung, wo die Lifecycle-Tags bei Relationen hin sollen.

Eine Regel “Setze es an die Features-Tags” ist m. E. nicht einfach, weil viele Mapper vermutlich den Unterschied zwischen Feature-Tag und Attribut nicht kennen. Ein Indiz dafür ist, dass es die Erklärung von “Feature” noch nicht ins deutsche Wiki geschafft zu haben scheint.

Zudem haben nicht alle Relationen ein Feature-Tag. Relationen mit ‘type=bridge’ z. B. haben mitunter kein anderes Tag. Dort scheint eher das ‘type=bridge’ das Feature-Tag.

Was haltet ihr davon, an die Relation einfach ein z. B. ‘disused=yes’ zu hängen? Dann ist klar, dass sich das ‘disused’ nicht nur auf das einzelne Tags der Relation bezieht, sondern auf die ganze Relation.

Nachteil wäre, dass die meisten Renderer das schlichtweg nicht auslesen werden. Mangels Menge wird da auch keine Motivation da sein, das zu ändern. Dadurch würden aber razed- oder was-Relationen weiter gerendert werden. Drum vermute ich wenig Akzeptanz für diesen Vorschlag.