shelter/bench/bin=yes bei separat gemappten Objekten

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:

Warum in eine Relation? Einzeln eintragen auf dem Geländer der Tankstelle. Dann kann ich eintragen, ob es in der Toilette einen Wickeltisch gibt oder eine mit wheelchair=yes oder bei Sitzbänken, dass sie “grün” sind und aus Holz mit 6 Sitzplätze ist. Einfach ist immer das einfachste.

Das mit den ÖPNV doppelt gemappt wird, ist aber auch Editorsache: “Gibt es an der Haltestelle einen Papierkorb? - ja / nein” Das da einer separat eingetragen, fragt der Editor ja nicht.
Hat die Haltestelle - weil wheelchair=yes - eine Rollstuhl-Toilette → toilets:wheelchair=no

Das war der Anstoß der ganzen Sache. Mir war das bei StreetComplete aufgefallen. Ich hatte dann gesehen, dass bereits jemand ein Ticket eröffnet hatte und vorgeschlagen hat, dass StreetComplete entweder auswertet, ob in unmittelbarer Nähe bereits ein entsprechendes Objekt vorhanden ist (was nicht funktioniert, wie hier bereits erwähnt) oder es die Antwortmöglichkeit geben sollte: “Vorhanden, aber bereits separat gemappt”. So eine ähnliche Antwort gibt es bei sidewalks inzwischen auch. Dort wurde darauf hingewiesen, dass beides parallel möglich sei. Ich fragte mich dann, ob dadurch nicht die “One feature, one OSM element”-Regeln gebrochen wird.

Weil all diese Objekte zur Tankstelle gehören und man Angaben wie Name, Betreiber, Anschrift, Kontaktdaten etc. nur an einer Stelle eintragen kann. Ähnlich auch Bäckerei und Café oder Hotel und Restaurant.

Naja, geht auch schnell andersherum :wink:
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dbus_stop&type=revision&diff=2186610&oldid=2186609

Habe DE:bin erstmal ohne Innovationen, nur aus EN aktuell ergänzt
https://wiki.openstreetmap.org/w/index.php?title=DE%3AKey%3Abin&type=revision&diff=2207914&oldid=2110339

Gerade dieses Beispiel: https://wiki.openstreetmap.org/wiki/DE:Key:bin#Beispiele

Der Mülleimer taucht dann 4 mal auf:

amenity=waste_basket
amenity=bench
bin=yes
amenity=shelter
bench=yes
bin=yes
highway=bus_stop
public_transport=platform
shelter=yes
bench=yes
bin=yes

Warum nicht auch:

amenity=waste_basket
bench=yes
shelter=yes

:wink:

Ich halte separate generell für problematisch, so lange die Objekte nicht im direkten Bezug (Relation?) stehen. Häufig wird eines der beiden Objekte vergessen anzupassen. Bei footway/path=sidewalk oder/und is_sidepath wird ja wenigstens noch versucht beiden Objekten diese Information anzuheften. Bei einzelnen Objekten, die sich nicht innerhalb einer Fläche befinden, wie Haltestellen am Straßenrand/Trottoir, wird da separate allein wenig bringen.