In Aachen (möglicherweise auch wo anders) scheint es üblich zu sein bei Bushaltestellen (public_transport=platform) die als Linie gemappt werden, diese mit der zugehörigen stop_position auf der Straße zu verbinden. Dies führt zum einen zu einer nach meiner Meinung irritierenden, räumlich falschen Darstellung auf der Karte, zum anderen erschließt sich mir der Sinn dieses Vorgehens nicht. Weiß da jemand mehr? Beispiele sind z.B. Aachen Elisenbrunnen: https://www.openstreetmap.org/#map=19/50.77424/6.08793&layers=N
Der Knick ist falsch. Oder hat man den Bordstein noch senkrecht zur Fahrtrichtung fortgesetzt, damit es gleich beim Anfahren (Überfahren des Bordsteins) schön holpert?
Der Fehler ist übrigens schon seit 2009 oder 2010 drin. Lies: Altes ÖPNV-Mapping, das nicht dein Vorbild sein sollte.
Wenn ein richtiges Busbord vorhanden ist bzw. ein echter Bussteig erkennbar ist, dann kann man Plattformen als Fläche oder Linie erfassen. Ansonsten sollte man nur einen Node (Haltestellenmast) mappen. Linien/Flächen sollten zwecks Routing mit dem restlichen Routingraphen verbunden sein, Nodes nicht.
Ich habe mir schon gedacht, das dies etwas historisches, bzw aus Kompatibilität ist. Mich hat irritiert, dass selbst in jüngster Vergangenheit offenbar Bushaltestellen nach diesem Schema neu gemappt wurden, z.B. “Scheibenstraße”. Das mapping scheint auch keinem existierenden Schema zu entsprechen, sondern eine wilde Mischform zu sein. Die Wikiseite zum Aachener Verkehrsverbund gibt auch nichts her und ist hoffnungslos veraltet. Also einfach ohne Rücksicht auf Verluste nach “Public-Transport Version 2” neu mappen? Hab irgendwie als Neuling Angst dann von irgendwelchen lokalen Platzhirschen geteert und gefedert zu werden.
Ich verstehe das nicht. Ich dachte, Plattformen sollten einfach neben der Straße liegen und in die jeweiligen Linienrelationen mit aufgenommen werden und zwar unabhängig ob als Punkt, Linie oder Fläche gemappt.
Moin,
ja, sie werden - egal ob Node/Way/Area - in die Buslinien-Relation mit aufgenommen - für das Busrouting.
Und ja - bis auf die Nodes - sollten sie auch mit dem restlichen (Fuß-)Wegenetz verbunden sein - fürs Fußgänger-Routing zur bzw. auf der Platform.
Gruß, Georg
So macht das natürlich Sinn. Ist noch die Frage, wie man diese Plattform-Linien sinvoll mit dem Weg verbindet, wenn es keinen separat gemappten Fußweg gibt. Ich frage mich aber auch, wie sinvoll solche Linien bei Bushaltestellen überhaupt sind. Die Haltepositionen sind zwar recht lang, aber als Fahrgast interessiert mich ja in erster Linie wo der Haltestellenmast und das Wartehäuschen ist.
Ich hatte das Problem des Fußgängeroutings hier schon einmal angesprochen.
http://forum.openstreetmap.org/viewtopic.php?id=53550
Vielleicht wäre es sinnvoll sich doch einmal auf ein Schema zu einigen und dies zu konkretisieren.
M.E. ist die zweimalige Verwendung von *=platform unnötig. Wenn der hw=footway wird (statt =platform), funktioniert das Routing mit ÖPNV und Fußgänger
Das Problem ist meiner Meinung nach nicht so sehr, ob an einer Haltestelle highway=footway statt highway=platform steht (Die Begehbarkeit sollte eine implizite Eigenschaft von public_transport=platform sein ). Die Frage ist, wie nicht Punktförmige Objekte mit dem vorhandenen Wegnetz verbunden werden sollen. Bei Bahnsteigen ist das meinst kein Problem, da diese in der Regel klar abgegrenzt sind und klar definierte Zugangswege haben. Anders ist es bei einem Busbord, die oft Teil des Gehweges welcher oft nur implizit durch die zugehörige Straße gemappt wird. Hier sollte man sich in der Tat einigen,was man da machen soll.
Da gibt es kein Problem mit mehreren Schemata. public_transport=platform stammt aus PTv2. PTv2 sagt da ganz klar, dass man es nicht benutzen muss und dass die anderen Tags durch PTv2 nicht geändert werden. Wenn man da keine zwei x=platform stehen haben will, dann kann man das public_transport=platform weglassen. Das Problem liegt im Routing: wenn ein Router meint, dass ein Bussteig nicht begehbar wäre, dann irrt er sich.
Weide
Der Router mal außen vor (warum setzen Verkehrsbetriebe keine Router von OSM ein?):
http://www.openstreetmap.org/way/396416644
http://www.openstreetmap.org/way/332829469
solche nicht vorhanden Konstructe sind m.E. nicht richtig.
Wenn ein footway und ein platform zusammenfallen sollte es schon ein (Fuß-)Weg sein. Die plattform ist eine spezielle Stelle (des Fußweges) für den ÖPNV, wo ein Umstieg zum/von ÖPVN möglich ist.
Auch auf einem Bahnsteigfläche sollte ein routing vom Fahrstuhl zur Treppe und zur Halteposition über einen footway möglich sein. Warum z.B. auf so einer Fläche nicht ein footway an beide Bahnsteigkanten (z.B. bei zwei Gleisen - auch wenn die Wege tatsächlich 50 cm neben der Kante verlaufen)?
Deine Beispiele zeigen doch klar, dass es nicht das Problem löst, die platform als Weg zu betrachten. Ohne diese nicht vorhandenen Hilfskonstrukte würden die platformen trotzdem noch unerreichbar bleiben. Hier bräuchte es vielleicht etwas um die Platformen als teil des angrenzenden Wegs zu taggen analog zu sidewak z.B. Platform=both/left/right/none.
Bahnsteigfläche haben in der Regel keine Wege, sondern sind als ganzes begehbar. Warum kann man da nicht über die Fläche routen? Das einführen “virtueller Wege” führt dann doch nur wider dazu, dass man alle Elemente wie Wartehäuschen, Treppe usw. mit nicht vorhandenen Wegen anbinden muss, damit man die erreichen kann.
Hallo zusammen!
Als jemand, der jetzt seit ein paar Jahren in Aachen lebt, wollte ich hier auch mal meinen Senf dazu geben.
Ja, ich habe mich auch schon des öfteren über die Aachener Eigenart, Bushaltestellen zu mappen, gewundert,
und ja, ich finde sie auch nicht korrekt.
Jetzt zum speziellen:
Sehe ich nur bedingt so.
In deinem Beispiel sieht man einen Busbahnhof. Hier nur highway=footway zu mappen finde ich grund falsch, da grade in Busbahnhöfen die Bussteige auch mal etwas länger sind und mehrere Busse an eine Haltestelle passen. Hier gehört definitiv ne Linie oder Fläche mit highway=platform (bzw. public_transport) hin.
Die Frage, wie man da zur Haltestelle kommt, sollte aber auf jeden fall Beantwortbar sein. Ab einer gewissen Komplexität sollte man Möglichkeiten haben, einen Weg zur Haltestelle aufzuführen und damit auch andere Möglichkeiten auszuschließen.
Von daher finde ich dein Beispiel zwar auch erst einmal falsch, auf den Zweiten Blick ergibt sich dennoch ein Sinn dahinter und für den späteren Benutzer erst recht.
Viele Grüße,
hsimpson
Ich stelle noch einmal das Bild meines ursprünglichen Taggings hier als Link ein, damit es "groß angesehen werden kann - auch die dazugehörige ÖPNV-Karte:
http://files.homepagemodules.de/b563523/pictures_u1021_mSeCOpIg.jpg
http://files.homepagemodules.de/b563523/pictures_u1021_mSeCOpIg.jpg
(Warum soll auf der Standartkarte der Bussteig zu sehen sein? Die Steignummer steht neben dem Fußweg und ist somit findbar. Der Fußweg wird auch (unauffällig) anders gerendert -.-.-)
Zu sehen das die hw als footway mit dem Zusatz platform an den betreffenden Stellen getaggt sind. Eine auswertung als Fußweg (für Router?) und eine Auswahl als platform (für ÖPNV?) ist gegeben.
Auch der ÖPNV Layer hat mich “verstanden”:
http://files.homepagemodules.de/b563523/pictures_u1019_cDpyxCqF.jpg
Dabei habe ich nichts weiter getan, als den (bisherigen) hw=platform als hw=footway und an den betreffenden Wegstücken public_transport=platform zu taggen.
Dann brauche ich nicht solche “zusätzlichen” Wegstücken.
Auch railway=platform ist nicht nötig, da es ja ein Fußweg ist und kein Schienenweg - public_transport=platform lässt für die ÖPNV-Karte die Auswertung zu.
Streiten kann man noch um way und Fläche. (Wobei ein Flächenrouting bei keinen Router ohne großen Aufwand eingefügt werden - bin ich für einen way als Bahnsteig. An einer Fläche kann ich auch bei Doppelbahnsteigen nicht die Nummer an der richtigen Linie eintragen.)
+1(geri-oc)
Lässt man highway=platform in der Mottenkiste, wo es hingehört, ist die Welt in Ordnung.
public_transport=platform ist der Bereich an dem Personen auf das Fahrzeug warten. Dies ist ein Bereich des Fußweges.
Bei Bahnhöfen (in Deutschland) ist die railway=platform gerechtfertigt, da der Bahnsteig baulich vom Schienenweg getrennt ist.
Auf dem VRR-Mapper-Treffen März 2015 (mit Vertretern von MentzDV) stellten wir fest, dass public_transport nicht routingfähig sein muss. Der früher mal angedachte Fußweg zwischen platform und stop_position ist überflüssig. Der Aussteigeweg läuft von der stop_position rechtwinklig auf die platform oder auf deren nächstgelegenen Eckpunkt.
Da liegt das nächste Problem: Der Steig ist doppelt gemappt. Damit kann die Datenbankabfrage nach den hier haltenden Linien nicht mehr funktionieren. Wenn man nachsieht welche Buslinien zum Haltestelleneintrag Node 3399454516 gehören, dann findet man keine Routen. Das liegt daran, dass die Haltestellen nicht in der Route stehen. Man kann sie auch nicht hinzufügen … dann hält der Bus dort zweimal wo er real nur einmal hält. (Er hält da aber laut Datenbank sowieso schon zweimal, weil wegen der verschiedenen Namen von stop und platform das Pärchen nicht als Pärchen erkannt wird).
Nodes mit highway=bus_stop neben dem Fahrweg sind platforms im Sinne von PTv2. Ebenso sind Nodes mit highway=bus_stop auf dem Fahrweg stop_positions im Sinne von PTv2. PTv2 hebt ganz ausdrücklich die alten Mappingarten nicht auf und verlangt ganz ausdrücklich keine Ergänzung durch neue Tags. Diese Nodes werden auch nicht erst durch einen Eintrag in Stoparea mit der Rolle platform zu einer platform. Dass sie dort mit der falschen Rolle eingetragen sind ist nur ein zusätzlicher Fehler.
Weide
Noch so ein Problem…
Lässt man highway oder railway=platform weg und verwendet nur public_transport=platform, rendert Mapnik - nix…
Von daher bin ich persönlich dazu übergegangen, bei den betroffenen platforms das highwar oder railway wieder hinzuzufügen. Ne Platform, die man auf der Karte nicht sieht, bringt dann ja auch nix.
Dieser häßliche graue Balken, gehört auch nicht auf die mapnik-Karte.
Die public_transport=platform wird auf der ÖPNV-Karte, der transport-Karte, der openptmap genutzt und bei der Auswertung von bus-routen.
Sinnvoll wäre das Haltestellensymbol auf der platform, aber da warten wir seit Jahren auf die Umsetzbarkeit.
Lezterem möchte ich voll zustimmen. Und Mapnik rendert die Bushaltestellen mit anderem Fußweg (-.-.-) und schreibt die ref=*dran:
http://files.homepagemodules.de/b563523/pictures_u1021_mSeCOpIg.jpg
und in ÖPNV sieht es so aus:
http://files.homepagemodules.de/b563523/pictures_u1020_YoVzpJHT.jpg
(Aktuell ist der Busbahnhof aber revertet - http://www.openstreetmap.org/#map=19/50.99892/13.64794))
Also wie man ein Kartenelement hässlich finden kann erschließt sich mir noch nicht so ganz, bei mir zählt eher die Zweckmäßigkeit. Und da gehe ich auf OSM.com um zu schauen, wie ich mich denn da an der Haltestelle zu orientieren hab (weil die Detailgenauigkeit da meist am höchsten ist). Und da Mapnik neben den Haltestellen am besten differenziert, nutze ich das.
Würden Bahnsteige nicht mehr gerendert werden würde das doch ein heiloses Chaos geben, z.B. am Kölner Hbf. Wenn man da alle Bahnsteige einfach als Fußwege rendern würde, könnte man die doch gar nicht mehr abheben vom restlichen Umfeld, etwa den Passagen.
Ich sprach von Bushaltestellen mit dem dominanten nichtssagenden dunkelgrauen Streifen, der nur verwirrt, wenn man sich gerade nicht mit ÖPNV beschäftigt.
Bei Bahnsteigen wie am Hbf Köln ist railway=platform durchaus sinnvoll. Der Bahnsteig setzt sich baulich ab und im übrigen gilt hier das railwaymap-Konzept.