StreetComplete, Haltestellen und Mülleimer

Hallo,
da fragt mich doch heute SC, ob es an der Haltestelle XY einen Mülleimer gibt. Meinen spontane Antwort wäre JA gewesen.

Aber Moment mal, da hatte ich doch schon einen Mülleimer gemappt. Separat, etwa 2m neben dem Wartehäuschen.

Soll ich jetzt die Frage mit Ja beantworten und den Mülleimer damit doppelt erfassen oder nicht?

Nee - SC nicht benutzen.
Sind schon so viele doppelte Einträge entstanden.
Auch das für jedes Dach, Etage, Gebäude, … immer ein extra CS angelegt wird.

ja

Warum? Damit SC noch einen zweiten Mülleimer daneben taggt?

Die erste Info ist eine Info über die Bushaltestelle. Das Mülleimerobjekt selbst hat die genaue Position und evtl. noch mehr Eigenschaften.

sehe ich auch so, =yes heißt das gibt es da, aber ob das dann noch explizit gemappt ist oder nicht kann man daran nicht erkennen (es gibt die separate-Idee damit umzugehen, die aber auch wieder andere Probleme schafft)

https://wiki.openstreetmap.org/wiki/DE:Ein_Objekt,_ein_OSM-Element

Das ist bekannt, steht aber nicht im Widerspruch, bin=yes ist kein Objekt das einen Mülleimer repräsentiert, sondern es ist ein Objekt das einen (oder mehrere) Mülleimer hat. Der Mülleimer ist von amenity=waste_basket repräsentiert.
Das ist wie bridge=yes auf einer Straße oder Schienenstrecke, die repräsentieren auch keine Brücke, dafür gibt es man_made=bridge

Das spricht dafür, dass der Ersteller des StreetComplet Request die Abfrage nochmal überdenken sollte. In etwa Bushaltestellen, die in 2 Meter Umkreis einen Node mit amenity=wastebasket besitzen, werden nicht angefragt (weiter sollte man nicht gehen, sonst trifft man notfalls die Bushaltestelle auf der anderen Seite :sunglasses:).

Ist denn an der Abfrage eine (interne) Referenznummer bekannt?

Ich wäre für eine andere Form: Man müsste gemappte amenity=waste_basket anzeigen und ggf. dann ein seperate als value angeben (tendenziell wäre ich sogar eher dafür, hier eigentlich sogar eine Beziehung irgendwie abzubilden…) Denn faktisch kann man das bin=yes auch als “hier ist ein Mülleimer” interpretieren. Steht ja im Wiki sehr gut mit: “Additionally, it may or may not be mapped as a nearby node with”. Es ist bisher eher inkonsistent.

mal was ganz anderes: hat jemals jemand in einer Karte nach einem Mülleimer gesucht?

:smiley:
Ja.

Das Problem hatte ich vor ein paar Monaten auch schon angesprochen. Betrifft z.B. auch Wartehäuschen (shelter) und Sitzbänke, die bereits separat erfasst sind.

Meiner Meinung nach ist das eine doppelte Erfassung und ich schlage auch vor, stattdessen bin/shelter/bench=separate zu taggen, wenn man diese Info unbedingt an der Wartestelle direkt benötigt. Ich sehe das analog zu Straße/Gehweg. Da wird das auch so praktiziert.

Ja, schon mehrmals! Wenn ich z.B. mit dem Hund unterwegs bin und gerne wissen möchte, wo ich die volle Tüte schnellstmöglich los werde. Nach einer Bushaltestelle mit Mülleimer habe ich aber noch nicht gesucht. Aber vielleicht steigen manche nur dort ein oder aus, wo es einen Mülleimer gibt. :wink:

Das Anzeigen vorhandener Mülleimer usw. ist aber schwierig mit der GUI von SC, zumindest dann, wenn es viele andere Aufgaben gibt, die in der Nähe gerendert werden. Man könnte als Antwortoption „ist separat auf der Karte“ einführen, wie das seit kurzem bei Bürgersteigen gemacht wird. Aber das macht die Benutzung schwieriger. Zwei Optionen zu haben ermöglicht einfache Wahlen. Bushaltestellen, wo im Umkreis von 2 Metern schon ein Mülleimer gemappt ist, auszufiltern klingt erst einmal reizvoll. Aber es gibt dabei einen Nachteil: Wenn man bei allen Bushaltestellen, unabhängig von der Frage, ob der Mülleimer separat gemappt ist, als Tag erfasst, ob ein Mülleimer vorhanden ist oder nicht, dann lässt sich das leicht auswerten. Aus meiner Sicht besteht die beste Lösung darin, das Vorhandensein von Mülleimern, Wartehäuschen und Blindenleitsystemen an der Haltestelle zu taggen. Separat erfasste Wartehäuschen, Mülleimer, Blindenleitsysteme, elektronische Abfahrtsmonitore usw. sollte man in die jeweilige Haltestellenrelation aufnehmen. Damit hätte man zwei Probleme gelöst: Erstens ist es leicht auszuwerten, welche typischen Ausstattungsmerkmale einer Bushaltestelle vorhanden sind und zweitens kann man die einzelnen Elemente der Haltestelle zuordnen, neben den weniger typischen. Damit ließe sich dann beispielsweise eine Mülleimer-Finde-App umsetzen, die Haltestellenmülleimer (im Standardmodus) nicht findet.

Ich bin bei Euch, wenn ein Haltestelle ein bin=yes erhält, dann ist es besser auszuwerten. Aber dann sollte die Frage lauten: Gehört der Mülleimer, der in der Nähe von der Haltestelle gefunden wurde, zur Haltestelle? Korrekterweise sollte man bin=yes nicht zum Rendern sondern nur zum Finden nutzen.

Ich habe inzwischen meine Meinung geändert: Eine Sitzbank, ein Mülleimer, ein Wetterschutz wird nur durch ein eigenständiges amenity-Objekt gemappt. Ein Tag bin/shelter/bench=yes/no an einem anderen Objekt ist nur eine zusätzliche und davon unabhängige Information, ob ein entsprechendes Feature vorhanden/nutzbar ist. Das könnte man zwar auch aus der geographischen Nähe ableiten, aber auch nicht sicher, da das Objekt vielleicht in der Nähe liegt, aber nicht erreichbar ist (z.B. auf der andere Seite von einem Zaun).

Mit dieser Sichtweise ist für mich die OSM-Welt plausibel. :wink:

Edit: Ich werde wohl bei Zeiten meine bin/shelter/bench=separate Einträge demnächst in bin/shelter/bench=yes ändern.

Das sehe ich auch so. Ich sehe es auch nicht als problematisches Doppelmapping, wenn man zum einen an der Haltestelle die Information mit anführt, was dort alles vorhanden ist (shelter, bin, …) und zusätzlich diese Objekte noch dort als Node einträgt, wo sie sich tatsächlich befinden. Das haben wir übrigens auch bei anderen Objekten, z.B. wird die Geschwindigkeitsbegrenzung als Zusatzattribut der Straße erfasst, manche tragen aber zusätzlich an der Stelle, wo das Verkehrsschild steht, auch noch das Schild ein, dass diese Geschwindigkeitsbegrenzung anordnet als Node ein.

Anders ist es leider bei Straßen. Da kann ein Gehweg durch ein sidewalk=yesright/left/both erfasst werden. Ein zusätzlicher highway=footway wäre dann nicht richtig bzw. eine doppelte Erfassung. Da gibt es das sidewalk=separate. Von daher mein ursprünglicher Standpunkt.

m.E. ist es bei Gehwegen auch nicht anders, oder bei Geldautomaten in Banken. Grundsätzlich sollten wir uns idealerweise auf eine Interpretation einigen, alles andere führt mehr oder weniger in die Hölle weil man für jeden tag (potentiell) endlose Listen durchsuchen müsste um zu verstehen was gemeint ist.

Das war zwar bislang die gängige Haltung, diese wackelte aber aus gutem Grunde in einer Diskussion, die vor Kurzem geführt wurde.

Das sehe ich inzwischen auch so und würde es begrüßen, wenn sich diese Einschätzung durchsetzte.