shelter/bench/bin=yes bei separat gemappten Objekten

Ist es OK, wenn man z.B. an einer Bushaltestelle shelter/bench/bin=yes taggt, wenn diese bereits als eigenständige Objekte gemappt sind? Ich dachte bis jetzt nein, wurde aber gerade eines besseren belehrt:

https://wiki.openstreetmap.org/wiki/Key:bin

https://wiki.openstreetmap.org/wiki/Key:shelter

Wundert mich nur, weil wir einen Bürgersteig auch nicht mit sidewalk=right/left/both + einem separaten highway=footway erfassen.

https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform sagt wiederum genau das Gegenteil:

Ja, alles andere ergibt wenig Sinn, sonst wüsste man z.B. nur, dass es dort mindestens einen Abfalleimer gibt, aber nicht wo. Bei Sitzbänken wüsste man nicht wie viele, wo, aus welchem Material, mit Lehne oder ohne, wie viel Sitzplätze, u.s.w.
Umgekehrt lässt sich von einem in der Nähe befindlichen Abfalleimer, Sitzbank oder Unterstand nicht sicher bestimmen, ob diese/r zur Haltestelle gehört/gehören, die räumliche Nähe dazu reicht hier nicht aus, insbesondere wenn sich eine Böschung, Hecke, Zaun, Mauer, Bach oder ein sonstiges Hindernis (evtl. auch nicht erfasst) zwischen Haltestelle und POI befindet.
Ein Fahrgast möchte aber wissen, ob er an der Haltestelle sitzend oder geschützt waren kann, also hat auch das “yes” seine Berechtigung neben den einzeln erfassten POI.
Ist so wie bei Straßenlaternen, da werden auch die Laternen erfasst und zusätzlich lit=yes am Weg.

Es gäbe noch die Möglichkeit analog zu sidewalk shelter/bench/bin=separate zu verwenden.

1 Like

Manchmal sind die Dinger auch in der public_transport relation vorhanden.
D.h. man kann über die Relation abfragen was die Haltestelle an Features hat und gleichzeit kann man so feststellen wo sich die Objekte befinden.

Die banalere Variante ist halt das als Hinweis an den POI zu pappen. Dann funktioniert die Abfrage für die Haltenstellen Features immer noch. Und dann die Dinger dennoch separat einzeichnen!

Hat im eigentlichen Sinn nichts mit den Objekten an sich zu tun sondern eher mit pubic_transport…

zumindest widerspricht das gleichzeitige implizite und explizite Mappen nach meinem Verständnis nicht der one feature one element Regel, weil einmal ist das Objekt gemappt, während in den übrigen Fällen (Property) nur angegeben wird, dass dort ein solches Objekt existiert bzw. solch ein service (Müllentsorgung) dort angeboten wird.

Nein, wir haben auch Objekte unabhängig von public_transport. Ein Wetterschutz kann man auch mit bench=yes/no und bin=yes/no attributieren. Oder ein Hundekottütenspender mit bin=yes/no.

In Zusammenhang mit public_transport ist es dann möglich, dass ein Mülleimer bei einem überdachten Wartebereich einer Bushaltestelle als amenity=waste_basket erfasst ist und dann zweimal als bin=yes am amenity=shelter und public_transport=platform erfasst ist.

Wenn das Konsens ist, dass bin/shelter/bench=yes gemeinsam mit separat erfassten Objekten ist, dann sollte man das Wiki diesbezüglich vereinheitlichen. Aktuell ist die Dokumentation widersprüchlich.

Ja, ist OK für mich. Anderes Beispiel sind Banken mit Geldautomaten, Rastplätze mit Toiletten usw. Sollte dann nur (einheitlich) dokumentiert werden.

im Prinzip würde sich das auch analog auf Fahrradwege anwenden lassen, bzw. könnte man auch eine Hilfestellung geben, also so was wie atm=separate bin=separate etc.
Keine Ahnung ob das Sinn macht, wartungsmäßig ist es eher kritisch, wenn der Mülleimer abgebaut wird nicht nur den Mülleimer zu löschen sondern auch noch bei anderen Objekten in der Nähe zu sehen ob sie Eigenschaften haben die auf einen Mûlleimer in der Umgebung hindeuten.

Naja, würde denken
“Additionally, it may or may not be mapped as a nearby node with amenity=waste_basket.” - ist eine realistische Lagebeschreibung
“If there is a […] that is not tagged separately with […]” - dagegen ein “frommer Wunsch”
schwierig zu “vereinheitlichen”:wink:

wobei noch das (D-)OSM-Problemchen hinzukommt, ob denn der bin als “bin” oder als “waste_basket” getaggt werden soll,
habe daher aus dieser Juli-Disk:
https://forum.openstreetmap.org/viewtopic.php?id=73390
noch eine aktuelle EN-bin Übersetzung fertig auf dem Schreibtisch liegen:
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch&oldid=2182135

bei der waste_basket=yes/no als “Tagging-Fehler” daherkommt - sofern da ein einvernehmliches Vereinheitlichen möglich ist ?

Das “zusätzliche” mappen als Property/Attribut ist zwingend notwendig.
Nur weil ein Mülleimer in der Nähe ist, ist damit nicht automatisch klar ob es da eine Zuordnung gibt und aus der Entfernung kann man das auch nicht schließen.
Es ist auch nicht wichtig ob der Mülleimer tatsächlich als separates Element existiert denn das nächst gelegene Objekt muss nicht zwingend das richtige sein!

Vielleicht ist es so etwas klar was ich gemeint habe. Wiki können wir gerne dementsprechend anpassen.

Ich finde, dass wenn OSM frühzeitig auf “has-property” priorisiert hätte, dann hätten wir viele Daten nicht redundant und kompliziert im Überfluss. Speziell beim Datenverbrauch. (Beispiel path vs “has-property”=sidewalk=no|yes|left|right|irgendwas")

Was shelter/bench/bin etc betrifft; das sind Eigenschaften (has-property) der Bushaltestelle, wo diese genau stehen, ist egtl. eher uninteressant, es sei denn, die stehen 100m weg … dann sind es aber keine Eigenschaften der Bushaltestelle mehr.

Oder anderes Beispiel, was hier vlt. nicht so gut reinpasst, aber das Prob imho besser illustriert: Autobahnen mit Seitenstreifen und Leitplanken.
Seitenstreifen ist eine has-property an der Autobahn, Leitplanken aber nicht, obwohl die genau so wie Seitenstreifen an einer relativ eindeutigen Position in der Landschaft rumliegen.

Wie meinst Du das? Ich meinte, dass man einheitlich dokumentieren sollte, dass xyz=yes getaggt werden darf, auch wenn das Objekt bereits separat erfasst wurde. Tag:public_transport_platform schließt das aktuell explizit aus. So kann man es jedenfalls verstehen.

Das verstehe ich. Macht auch Sinn. Man verliert aber etwas an “Eindeutigkeit”: Wenn man z.B. die Anzahl Sitzbänke oder Mülleimer in einer Stadt ermitteln möchte, geht das dann nicht mehr, da ein bin=yes an einer Bushaltestelle, einem Wetterschutz, einem Kottütenspender, etc. nicht einfach mitgezählt werden können, da die Objekte bereits separat erfasst sein können.

Ich bin hier auch für separate statt yes. Hab ich auch vereinzelt schon angewandt.
Einfach um klarzumachen, dass der shelter der Bushaltestelle der gleiche ist wie der, den ein fleißiger Kollege 2,50m weiter separat erfasst hat.

1 Like

Ob “yes” oder “separate” dürfte wenn nicht ausdrücklich auf den tag sondern auf den key abgefragt wird egal sein.

Bezüglich den “2,5m weiter”… Das geographisch nächste ist nicht automatisch das richtige Objekt!

Hab schon mehrfach ÖPNV-Relationen gesehen in denen “diese Objekte” (Mülleimer, …) auch Teil der Relation sind. Ob so gängige Praxis ist weiß ich nicht. Aber so klappt die Zuordnung halt zu 100%. Und das Attribut kann man sich auch schenken (theoretisch) da sich die Infos aus der Relation ermitteln lassen.

Gleiches gilt bei Tankstellen:

Hier hatte ich auch schon darüber nachgedacht, ob es Sinn macht alle separat gemappten Features einer Tankstelle (Waschanlage, Pressluft, Shop, Toiletten, etc) in eine site-Relation zu packen.

Das Erfassen von Objekt x als Einzelelement UND als Subtag an einem anderen OSM-Objekt ist datentechnisch problematisch - realistisch betrachtet dürfte dies aber in den OSM-Daten häufig der Fall sein, insofern sollte dies dann auch (warnend) so dokumentiert werden.

Ich wollte vorallem aber darauf hinweisen, dass der Subtag bin=yes/no auch als waste_basket=yes/no erfasst sein kann - was in der DE-bin-Dokumentation z.Zt. nicht (warnend) erwähnt wird, vgl. Links in #9.

Der undokumentierte Rätsel-value “separate” ist dann ein weiteres Problem…

Das Zusammenfassen der einzelnen Objekte in der stop_area-Relation ist doch schon lange möglich, wenn es darum geht die Objekte einer Haltestelle zu sammeln. Der Unterstand, die Bank und der Mülleimer bekommen eine leer Rolle und gut ist.

Ob separate als Wert uns jetzt groß weiterbringt, mag ich bezweifeln. Da steckt mMn. nicht viel Mehrwert drin und die Fehlererkennung bzw. Zuordnung wird ohne Verknüpfung der Objekte auch nicht besser.

Es wäre immerhin klar, dass das Objekt bereits als eigenständiges OSM-Objekt erfasst wurde. Bei meinem Beispiel (Ermittlung der Anzahl an Sitzbänken in einer Stadt) hilft es das Objekt nicht doppelt zu zählen.

… schön wäre es, aber
Erstmal führt der undokumentierte Key dazu, dass die dokumentierte yes/no-Auswertung zerschossen, unbenutzbar wird.
Zum zweiten ist nicht gesichert, das jeder Mapper dies im Sinne von “ist separat in OSM-gemappt” benutzt, statt “liegt seperat (etwas abseits der Haltestelle)”.

Wenn man die Zusatzinfo “ist zusätlich separat und lagerichtig in OSM-gemappt (bei Auswertungen ggf. beachten)” unterbringen möchte, dann ist undokumentierte shelter/bench/bin=separate imho eine schlechte Idee,
da wird man nicht um einen weiteren Tag herumkommen, wie bin:osm_separate=yes

Naja. Abgesehen davon, dass das Wiki die Mapping-Praxis dokumentiert: Den Value “separate” gibt es bereits für andere Keys und ist grundsätzlich definiert und dokumentiert. Siehe z.B. sidewalk=separate oder ramp=separate bei Treppen: https://wiki.openstreetmap.org/wiki/Key%3Aramp. Außerdem wird dadurch keine Abfrage xyz==yes; xyz==no oder xyz!=no “zerschossen”. Die funktionieren auch weiterhin wunderbar.

Das dokumentieren im Wiki geht auch schnell… :wink: