wozu braucht man shelter_type=public_transport?

Ich bin beim zusammenstellen meiner Liste mit sinnvollen mappingtags mal wieder auf eine Unlogik gestossen, die mir vielleicht jemand erläutern kann:

Was ist der Unterschied zwischen public_transport=platform shelter=yes und amenety=shelter, shelter_type=public_transport?

Mir erscheint das erstmal nich logisch da ein Bushaltestellenhäuschen sich ja genau durch die Anwesenheit einer Bushaltestelle definiert. Also ist der shelter_type völlig ueberfluessig, da es ja einen Tag fuer ueberdachte Bushaltestellen gibt.

Oder uebersehe ich einen Aspekt?

Ein (public_transport=platform shelter=yes) ist ein ziemlich grosses Gebilde, auf dem irgendwo ein Häuschen steht. Wenn man das (oder die vielen) Häuschen detaillierter Erfassen möchte, muss man das Bauwerk auch mappen können. Eben als shelter.

Grüße Max

Es gibt keinen! Das ist beides genau das gleiche und zu 100% redundant. Ich teile auch nicht die Auffassung dass es eine Notwendigkeit gibt das Wartehäuschen noch separat zu erfassen wenn public_transport=platform ein Weg oder eine Fläche ist, so groß sind Bushaltestellen nach meiner Erfahrung nicht. Und in allen anderen Fällen sollen nach der strengen Definition beide Nodes auf exakt derselben Position sein.

So ein Quatsch… :rage:

Ich finde es nützlich, zu wissen, dass ich auf dieser kleinen Fläche an diesem grossen Bahnsteig einen Regenschutz habe. Ich verwende das Häuschen auch gelegentlich zur Wegbeschreibung und als Treffpunkt.

Grüße, Max

Ja klar, än Bahnhöfe mit ihren elend lången Bahnsteige habe ich nicht gedacht. Bei Bushaltestellen Und auch Strasenbahnen schien Mir das doppelt gemoppelt.

Als Auswerter weiß man den Unterschied zu schätzen. Eine Karte für öffentliche Verkehrsmittel wertet public_transport=platform aus und kann shelter=yes als deren Eigenschaft nutzen. Für eine Outdoor-Karte dagegen ist amenity=shelter von Vorteil und es kann shelter_type=public_transport genutzt werden, um damit gesäumte Straßen zu vermeiden (für’s Gelände nicht nötig bzw. Standard bei Bushaltestellen).

Oder “public_transport=platform / shelter=yes” ist ein einziges Element, wohingegen “amenity=shelter / shelter_type=public_transport” auch ein Teil von public_transport=platform sein kann.

Das eine ist ein Wartebereich für Passagiere mit der Anmerkung, dass man da bei Regen nicht nass wird. Das andere ist ein Gebäude mit einer Anmerkung über seine Bauweise.

Ist denn ein Wartehäuschen, egal ob ummauert, verglast (vielleicht mit Tür) oder teilweise offen erbaut ein shelter:type=public_transport auch im Sinne der widersprechernden ÖPNV-Mitmapper?. Also nicht nur ein einfaches Dach an der Busstation, bei dem es reicht, ein shelter=yes zu mappen. Bei dem unteren Satz auf der dt. Wiki hat man den Eindruck, Shelter-Gebäude am Bus-und Bahnsteig könnte man bedenkenlos weglassen. Wenn der ersten Frage zugestimmt wird, ergänze ich auch die deutsche Seite mit vielleicht diesem Beispiel:

Auch ein “Glashäusel” ist für mich ein shelter:type=public_transport. Der Sinn des Unterstandes ist m.E. maßgebend.

Außerdem finde ich es im englischen WIKI. Der Satz wurde erst von einem User hinzugefügt und das Beispiel entfernt:
http://wiki.openstreetmap.org/w/index.php?title=DE:Key:shelter_type&diff=next&oldid=1307563

Leider ist das im WIKI auch jederzeit von jedem möglich …

Hier sage ich nur “Na ja”. Ist die Beschreibung nicht gewollt?

P.S.

Da ich den User kenne, möchte ich hinzufügen, er bearbeitet im Hintergrund viele OSM-Wikis aber diskutiert ungerne. Hier wäre es nicht schlecht, wenn er auch mal im Forum was dazu sagt. Ich halte mich allerdings zurück.

Als notorisch widersprechernder ÖPNV-Mitmapper sage ich:

Solange das Ding selbst nicht gemappt ist und bloß das Vorhandensein an der Haltestelle vermerkt wird (Regenschutz, Mülleimer, Sitzbank, Blindenleitbelag) ist das ne ÖPV-Angelegenheit. Aber sobald das Ding an sich gemappt wird, sollte das shelter=yes bei den ÖPV-Daten raus und die ÖPV-Leute sollten sich nach dem richten, was in dem Bereich üblich ist. Ich sehe da keine Probleme, wenn so ein schön ausgebautes Häuschen an der Bushaltestelle z.B. shelter:type=weather_shelter bekommt.

shelter_type DE Wiki ergänzt.
Es dürfen weitere Kommentare eingefügt werden, um die Beschreibungen selbsterklärend zu ergänzen.

Ein Buswartehäuschen ist ein Buswartehäuschen - auch wenn es ein einfacher Wetterschutz ist. Wenn dort keine Haltstelle wäre, wäre sciher auch kein Wartehäuschen - oder es handelt sich um eine ehemalige Haltestelle.

Und der Kommentar “Für eine einfache überdachte Bushaltestelle benutze public_transport=platform + shelter=yes” gehört nicht rein. Dann schon ein Link auf Bilder von shelter_type in anderen Ländern, und dort ist ein Wetterschutzdach auch ein shelter_type=public_transport

https://www.google.de/search?q=warteh%C3%A4uschen&newwindow=1&client=firefox-b-ab&source=lnms&tbm=isch&sa=X&ved=0ahUKEwif4_im5qLQAhVEPBoKHT9WB60Q_AUICCgB&biw=1152&bih=597#newwindow=1&tbm=isch&q=warteh%C3%A4uschen+bushaltestellen

Es kann (so einfach) getaggt werden - aber nicht wenn ein shelter extra eingezeichnet ist. Das ist das gleiche mit “Papierkorb”.

Und es gibt unterschiedliche Typen. Irgendwo habe ich einmal “gelernt”: Maßgebend ist das engl.WIKI. Es wird auf den Länderseite immer mehr spezialisiert - wovon andere Länder nichts wissen. Dadurch entstehen auch mehrfache Schlüssel, die eigentlich das gleiche (oder doch das ähnliche) aussagen.

Warum machen (notorisch widersprechernder) ÖPNV-Mitmapper nicht einmal “ein” ordentliches Schema?
public_transport=platform
highway=platform

Zwei Werte mit unterschiedlichen Schlüsseln müssen nicht sein.
Der highway ist immer ein Fußweg, wo Menschen sich zu Fuß bewegen, auch wenn er über eine public_transport=platform verläuft.

Schönes WE …

Ja. Und noch schlimmer ist es, wenn das gleiche Tagging regional oder nach Verkehrsmitteln verschieden interpretiert werden soll.

Hab ich. Auf http://gafte.de/
Aber das Interesse ist gering.

Weide

Es gibt in OSM die Regel “Don’t map for the renderer”. Die sollte – auch bei solchen Diskussionen – mehr beachtet werden.

Die OSM-Daten dienen anders als z.B. die Datenbanken von Verkehrsbetrieben keinem speziellen Zweck. Sie können aus diversen Gesichtspunkten bzw. mit diversen Interessen betrachten und ausgewertet werden. Beispiele:

  1. Bei einer an Fahrgästen orientierten, allgemeinen ÖPNV-Auswertung ist wahrscheinlich shelter=(yes|no) am leichtesten, schnellsten und sichersten auswertbar. Deswegen sollte es meiner Meinung nach immer gesetzt sein.

  2. Bei einem Detailplan der Haltestelle ist wahrscheinlich interessant wo der Unterstand genau ist und welche Ausmaße er hat. Daher sollte er mit amenity=shelter, shelter=public_transport eingetragen sein.

  3. Für einen 3D-Plan der Umgebung sind noch wesentlich mehr Details interessant. Da sollten building=roof und die Simple 3D Buildings-Tags gesetzt sein.

  4. Um die Wartbarkeit zu verbessern (Überprüfen der Einträge, neue Details mappen für die es vielleicht erst neue Keys gibt) und theoretisch z.B. auch für Rollstuhlfahrer sind Fotos (v.a. Mapillary und OpenStreetView) sehr sinnvoll.

Allgemein gibt es wahrscheinlich keine Daten, die in OSM überflüssig sind, sofern sie korrekt und einigermaßen wartbar sind. Es kann jederzeit jemand auf eine neue Idee kommen was man sinnvoll mit den Daten anfangen könnte. Nochmal Beispiele:

  1. Eine Audionavigationslösung für Blinde könnte an der Haltestelle den Weg zum Wartehäuschen weisen. Das geht natürlich nur wenn exakt bekannt ist wo das Wartehäuschen ist.

  2. Nachts im strömenden Regen könnte ein Audioassistent ala Siri/Cortana sagen: Auf der anderen Straßenseite, zehn Meter die Straße weiter ist ein Wartehäuschen mit Bank. Der Bus kommt erst in einer halben Stunde. Geh am besten dort hin. Ich sage dir eine Minute bevor der Bus kommt nochmal bescheid.

Das ist alles technisch schon möglich. Der Verkehrsverbund Rhein/Ruhr hat z.B. alle Busse mit GPS ausgerüstet und per proprietärer VRR-App kann man sich anzeigen lassen wann genau der Bus kommen wird (also inkl. Verspätung). Dafür müsste es eine offene API geben. Und die Daten in OSM müssten detaillierter sein.

Nebenbei: Man kann ja auch Abfahrtszeitentafeln mit tourism=information, information=board, board_type=public_transport mappen. JOSM meckert leider immer wenn ich eine so gemappte Abfahrtszeitentafel mit in die Haltestellenrelation eintrage. Falls jemand mitlesen sollte…

@Reclus Danke für den umfangreichen Beitrag. +1
Ich sehe es auch so, das sich ein shelter Tagging an einer Haltestelle sich nicht widerspricht (aber nunmal doppelt gefestigt ist) mit dem Eintrag shelter=yes. Da ich mich, wenn es die Zeit erlaubt, auch dem 3D Tagging zuwende, wie vielleicht andere Mapper auch, muss zwangsläufig ein Gebäudetagging auch hier erfolgen. Wobei dieses bei teiloffenen Shelter-(Gebäuden) auch noch nicht definiert ist. Egal.
Allerdings weiß ich auch noch nicht, wie ein solcher Shelter in die ÖPNV Struktur und Relationen eingebunden werden kann.
Braucht imho auch nicht. Bei der public_transport Beschreibung heisst es ja auch bei shelter=yes:
“Bereich besitzt Wartehäuschen oder Unterstand, nur wenn nicht separat mit amenity=shelter getaggt.”
Damit erübrigt sich wohl die ganze Diskussion.

Wichtig ist, dass im Wiki erläutert wird, wann welches Tagging anzuwenden ist und warum.

Ich mappe immer building:levels=1, building:min_levels=1. Beispiel: Unterstand Witten, Johannisstraße

Eine Haltestellenrelation trägt man als public_transport=stop_area ein. Den separat gemappten Unterstand fügst du dieser Haltestellenrelation hinzu. Beispiel: Witten, Johannisstraße

ÖPNV-Mapping ist aber kompliziert. Ich habe mich auch erst spät damit beschäftigt.

Warum nicht shelter:type=public_transport ?

Ja, es wäre einfach, wenn man gleichzeitig ÖPNV Mapper und Building/3D Mapper ist. Scheint ja bei dir der Fall zu sein.
Allerdings machen es sich die meißten ÖPNV Mapper einfach, wissen vielleicht über irgendwelche Quellen, das dort eine überdachte Haltestelle ist und taggen dann shelter=yes. Wiederum andere nicht ÖPNV Mapper, (inkl. mich), sehen eine überdachte Haltestelle und mappen dann zuhause, u.U. in 3D, diesen Shelter, ohne auf die ÖPNV Relation zu achten.
Ich denke, das ist ein Problem der Spezialisierung im Mapperwesen.

Genau! Habe daher hier den Kommentar für public_transport nochmals angepasst.