wozu braucht man shelter_type=public_transport?

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.

Ich sehe da kein Problem. Es kann ja jeder das mappen was ihn interessiert. Nur sollte man nicht darauf bestehen, dass sein eigenes Interesse, sein eigener Anwendungszweck das/der einzig Wahre wäre, die Daten der anderen überflüssig und vielleicht sogar zu löschen wären.

Klar, ist auch OK und der Normalfall. Es ging mir um was anderes: es geht nichts im ÖPNV kaputt, wenn jemand das Gebäude nicht als shelter:type=public_transport einstuft. Selbst das Weglassen in einer eventuell vorhandenen stop_area ist nicht weiter tragisch.

Drei tags für einen Fahrplan ist mir zuviel, ich tagge für diesen Zweck einfach ein timetable=yes an die Haltestelle.

Das ist ja die gleiche Frage wie bei shelter=yes vs. amenity=shelter, shelter_type=public_transport. Meine Position dazu s.o. Je mehr Details desto besser.

Aber danke! Ich kannte diesen Key noch nicht. Er ist ja auch im Wiki nicht beschrieben aber wird aktuell 3333 mal verwendet und ist damit ja scheinbar etabliert. Ich werde timetable=(yes|no) wahrscheinlich in Zukunft zusätzlich mappen.

Also ich kann Reclus nur beipflichten. Es gibt keine Daten, die überflüssig sind, solange sie nicht falsch sind. Und die Erläuterung, dass unterschiedliches Tagging für den gleichen “Gegenstand” für eine Vielzahl von Anwendungen sinnvoll ist.
Man könnte ja fast andenken, ob man die Tags neu strukturiert, also eher anwendungsbezogen benennt. Aber das ist ein vermutlich illusorischer Kraftakt. Könnte man aber für zukünftige Tags andenken.

Blöd sind redundante Daten ja nur dann, wenn sie sich widersprechen.

Und unlogisch ist die Kategorisering im shelter_type ja auch. Soweit ich das sehe, Beschreibungen sich manchmal die Form, manchmal die Funktion Aber publuc_transport macht weder noch…

Edit: versehentliche verdopplung gelöscht

Das wäre eine Gelegenheit für die Qualitätssicherung. Ein QS-Werkzeug wie Keep Right könnte solche Widersprüche als Fehler anzeigen.

Bei der Auswertung sollte diese Redundanz keine Probleme nach sich ziehen. Naheliegend wäre zumindest, dass wenn shelter=(yes|no) gesetzt ist nicht weiter gesucht wird.

Apropos Redundanz und deren Sinn oder Unsinn:

Im Wiki wird bezüglich Bäumen davon abgeraten, genus=* zu setzen falls species=* gesetzt sein sollte da sich die Gattung aus der Spezies ermitteln lässt. Bei leaf_type=* wird dagegen (aus gutem Grund) nicht dazu geraten, es wegzulassen falls genus=* oder species=* gesetzt sein sollte. Diese Information lässt sich theoretisch natürlich ermitteln aber nur mit relativ viel Aufwand.

Wenn man mit den OSM-Daten vorhat, die Gattungen von Bäumen auszuwerten, ist es ein riesiger Aufwand, jeweils von der Spezies auf die Gattung zu schließen. Man braucht ein riesiges botanisches Wissen mit entsprechend großen Tabellen im Hintergrund. Naheliegend wären meiner Meinung nach zwei Lösungen dafür:

  1. Man mappt immer zusätzlich zu species=* auch genus=* (also mehr Redundanz)

  2. Man mappt auch species:wikidata=* (und *genus:wikidata=**) (verknüpft OSM also mit Wikidata)

In der freien Datenbank Wikidata ist dieses botanische Wissen, welche Spezies zu welcher Gattung gehört, maschinenlesbar enthalten. Meiner Meinung nach sollte man beides machen. Weggelassen werden könnten dagegen species:LG=* und *genus:LG=**, also die Bezeichnung der Spezies/Gattung in diversen Sprachen.

Hallo zusammen,
da ich selber die hiesigen Buswartehallen (heißen tatsächlich so) gemappt habe, ein paar Anmerkungen.
Es kommt oft vor das die Wartehäuschen nicht direkt an der eigentlichen Haltestelle sind.
Daher können dort schon mal ein paar Meter dazwischen sein. Z.B. hier:
http://www.informationfreeway.org/?lat=51.01680296614507&lon=7.182467184032419&zoom=17&layers=B0F00000
Oder hier:
http://www.informationfreeway.org/?lat=51.043155366489756&lon=7.20356543557381&zoom=17&layers=B0F00000

Daher zeichne ich die auch getrennt ein, bei einem überdachten Bahnsteig sieht das anders aus.
Zumal die Haltestelle total unterschiedlich eingezeichnet waren, mal auf, mal neben der Straße etc.

Betreiber sind auch nicht die Verkehrsunternehmen, sondern die Stadt. Zumindest hier bei mir.
Meist das Grünflächenamt, die auch die Papierkörbe lehren.

Ich nutzt sie gerne zum unterstellen wenn es bei einer Radtour plötzlich mal losschüttet, da will ich nicht lange suchen.

Wie die Diskussion hier zeigt wären wenigstens einheitliche Spezifikationszeichen schon sehr entwirrend.

Es heisst aus was für grunden auch immer shelter_type Und nicht shelter:type