shelter/bench/bin=yes bei separat gemappten Objekten

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.

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…

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
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

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.

@skyper: Das Problem ist doch bei bin=yes/no genauso vorhanden.

Ich sehe es für problematisch an, das aus den Übersichten im Wiki und den {{Tag/Key/Value}} Links der Status nicht hervorgeht. So landet das alles in einem Topf und es ist nötig auf jeder einzelnen Seite den Status nachzuschauen.

Ja, und separate macht es nicht wirklich besser.

Nein, aber es löst immerhin ein anderes Problem.

… meinst Du mit “Status” die Anzeige(möglichkeiten) von/durch taginfo-Vorlagen:
https://wiki.openstreetmap.org/wiki/Template:Taginfo
?