Das halte ich auch für falsch.
Zum Einen sollte der Router die Leute nicht auf der Bahnsteigkante balancieren lassen und zum Anderen wäre dies Tagging für den Rooter.
Ein guter Router sollte über die Bahnsteigfläche routen.
Auch die Querwege zur Verbindung mit der Platform sind eigentlich falsch. Hier wäre es wohl korrekt, die Treppenbereiche per Multipolygon-Inner aus dem Bahnsteig auszuschneiden und den Fussweg (die Treppe) dann mit dem Inner und damit der Bahnsteigfläche zu verbinden.
“highway, railway, platform” sind nicht an einem way sondern an dem Multipolygon.
Das “highway=platform” ist Quatsch, denn das Ding ist klar nur für Züge. Das “area=yes” ist auch Quatsch, denn Multipolygone können nur Flächen sein und area=yes gehört nur an Objekte, die ohne das Tag Flächen oder Linien sein könnten.
OK. Das Flächenrouting funktioniert nicht. Das ist ein Routing-Problem und es muss entweder gelöst werden oder wir müssen in OSM generell auf begehbare Flächen verzichten … was nicht passieren wird.
Außerdem meinen die Routing-Engines augenscheinlich, dass man auf einem Bahnsteig nicht gehen kann. Das ist einfach ein Irrtum.
OK, dann hätten wir da an einem Bahnsteig drei Platforms – falls ich das richtig verstanden habe.
Das kann PTv2 nicht. Jeder stop und jede platform, an der ein Verkehrsmittel hält, muss in die Route, sonst ist das Nachschlagen der Linien zu einer Haltestelle kaputt. Pro Anhalten des Fahrzeugs kann eine PTv2-Route aber nur maximal einen stop und eine platform aufnehmen, sonst geht die Haltestellenliste der Route kaputt. Ein Konzept mit solchen Platforms ist möglich, aber kann man es erst nach Ablösung von PTv2 realisieren. (In meinem PTv3-Vorschlag geht sowas)
Mentz legt in OSM nichts fest! Nach unserem Anfangskonflikt mit Mentz hat sich da eigentlich auf dieser Basis ein gutes Verhältnis entwickelt.
In der Rolle geht es nicht. Sowas ging in PTv1, weil PTv1 eigentlich keine Rollen hatte und brauchte und man da dann einfach Zusatzangaben in der Rolle unterbringen konnte. In PTv2 hat man wie in Abbiegerelationen usw. aber echte Rollen, die für die Interpretation benötigt werden. Wenn man da was anderes reinschreibt oder was zusätzliches, dann ändert man die Auswerteregeln und macht korrekte Programme kaputt. Auswerteprogramme dürfen sich darauf verlassen, dass man in PTv2 mit einem Auszug der Relationsmember mit leerer Rolle die Liste der Fahrwege bekommt.
Tags an der Linie oder Variante wären sinnvoll. Da gibt es ja einige Varianten für “Zwischendurchstops”: “Ein- und Aussteigen”, “nur Aussteigen”, “nur für Frauen”, “erst ab 19:00”. Da müssten wir mal überlegen, wie man die ganzen Kombinationen sinnvoll in ein oder mehrere Tags packen kann…
Scheint prinzipiell ein lösbares Problem zu sein, wenn auch nicht ganz triviel: https://www.youtube.com/watch?v=6zzPzZgI3nY&t=1142s&index=45&list=PLTli5-lbeoibm_kIG8rk-6XIffh6HfM7r
Bahnsteige sind natürlich immer begehbar, aber eventuell nicht ohne rechtliche Einschränkungen. Meines Wissens nach sind Bahnsteige kein öffentlicher Raum, obwohl das gerade bei kleinen Haltepunkten nicht ersichtlich ist und Bahnsteige sogar hin und wieder im Hinblick als Zweitnutzung als Verbindungsweg angelegt werden.
Ich meinte auch nicht das Mentz etwas festlegen soll, sie sollten aber ihre eingeführten (z.B. sinnvollen Schlüssel = Anzeigetafel - destination_display) im WIKI - http://wiki.openstreetmap.org/wiki/DE:Public_transport - mit aufführen:
https://taginfo.openstreetmap.org/keys/public_transport#values
Damit wird schon etwas auf Vereinheitlichung eines Schlüssels hingearbeitet. Und da sie sich hauptsächlich mit ÖPNV beschäftigen und auch Daten nutzen, wäre eine Art “Moderator für ÖPNV” angebracht.
Ja. Einige der Verfahren sind evtl. für OSM nicht so geeignet. Wir haben wegen unterschiedlicher Namen oder Bodenbeläge oder wat-weiss-ich ja auch Flächen, die an Flächen statt an Wege grenzen. Da kann man dann nicht mehr davon ausgehen, dass Anfang und Ende der optimalen Route auf vorhandenen Nodes liegen. Ein paar Algorithmen entfallen dann schon. Der Rest kann heftig in die Rechenzeit gehen.
Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen. Wie in dem Vortrag gesagt wurde sind die jetzigen Lösungstricks ein wirklich störendes Problem für das echte Flächenrouting. Wenn man sowas dagegen offiziell zulässt, dann sind sie beim Rendern und beim Flächenrouting leicht zu ignorieren und das hätte auch noch einen großen Nutzen für den ÖPNV:
Wenn man als Fußgänger einfach einen Weg von A nach B sucht und stolpert dabei über eine querliegende Fußgängerzonenfläche, dann denkt man “wat n Blödsinn” und sucht sich selbst einen Weg. Wenn das bei Fahrplanauskünften passiert, dann bekommt man einfach eine schlechtere Verbindung mit Umsteigen in Düsseldorf statt in Köln. Dass das Ganze am Mapping des Bahnhofsvorplatzes in Köln liegt ist dann praktisch unsichtbar.
Funktioniert auch in Dresden gut: http://www.openstreetmap.org/#map=17/51.05974/13.74228
Dann würde es mit hw=footway an der Kante des Bahnsteiges auch besser funktionieren:
(Und so genau ist Routing (noch) nicht, das ich auf der Kante entlang balancieren muss.)
Wenn ich das richtig sehe, würde sich das lösen lassen in dem in der Vorverarbeitung der Daten zum Routing, benachbarte, begehbare Flächen zusammengefasst würden.
Wenn solche Wege geduldet werden, sollte da in der Tat ein tag dran, dass sie vom rendern ausschließt. Ich bezweifle allerdings, dass solche Hilfswege generell die Lösung sind. Sobald man komplexere Flächen hat, wäre die Anzahl der Hilfswege um von jedem sinnvollen Startpunkt kürzt-möglich zu jeden sinnvollen Endpunkt zu kommen sehr groß. Die Bereitschaft, Diese konsequent anzulegen, zu warten und überhaupt das Konzept zu verstehen dürfte gering sein. Triviale Fälle sind auf der anderen Seite auch gut automatisiert zu behandeln.
Insgesamt würde ich sagen, dass ich stark anzweifle, dass Menschen im allgemeinen deutlich besser darin sind Wege über Flächen zu finden als Maschinen. Ich denke, dass bisher nur zu wenig Aufwand investiert wurde, brauchbare Algorithmen zu implementieren.
Hier noch ein Video zum Flächenrouting von Roland Olbricht: https://www.youtube.com/watch?v=-ogblIKiN5M
Ein Tag zur Kennzeichnung solcher Wege halte ich für sinnvoll. Allerdings sehe ich bei begehbaren Flächen in der Regel keine Notwendigkeit solche Wege für Fussgänger anzulegen. Ein Fussgängerrouter routet über kurze Entfernungen und sollte dabei ein Flächenrouting beherschen. Wir sollten den Router-Entwicklern keinen Grund liefern, dieses niedrig zu priorisieren, zumal die Routing-Support-Wege hier im Allgemeinen auch keine guten Resultate ermöglichen dürften.
Grundsätzlich dürfen sich Auswerteprogramme gar nicht darauf verlassen, dass OSM Tagging Schemas unveränderlich sind, sofern man von unangekündigten plötzlichen Massenedits absieht. Insbesondere bei Änderungen, auf die die Auswerter mit minimalen Code-Änderungen reagieren können, sollten wir uns absolut keine Gedanken über Inkompatibilitäten von Auswerteprogrammen machen.
Da PTv1 Rollen für die Fahrwege verwendet und PTv2 nicht, wäre die Ergänzung sogar einfacher in PTv2 zu integrieren. Aber natürlich können wir auch mehrere Eigenschaften durch geeignete Syntax in einer Rolle kodieren, falls nötig.
Da ich für die Erweiterung keine hohe Priorität sehe, würde ich sie eher in ein generell überarbeitetes PTv3 (oder PTv2.x) einfließen lassen, wenn wir die Erweiterung haben wollen.
Unnötig oft müssen wir die Auswerter auch nicht mit Inkompatibilitäten ärgern und PTv1 und PTv2 sehe ich ohnehin als gescheitert an.
Die allgemein nötigen Änderungen halte ich für umfangreich genug, dass es ein PTv3 geben muss, eventuell ist aber ein PTv2.x als Vorbereitung dazu sinnvoll.
Nein. Andersrum wird ein Schuh draus. PTv1 verwendet keine Rollen als Rollen und PTv2 verwendet sie. Die leere Rolle ist eine Rolle wie alle anderen.
Die Rolle gibt ja an, was das Objekt in der Relation soll. Typisch ist z.B. “from”, “via” und “to” in Abbiegerelationen.
PTv1 verwendet keine Rollen. Haltestellen werden daran erkannt, dass sie Nodes sind. Fahrwege werden daran erkannt, dass sie Ways sind. Die Rollen sind also unbenutzt und werden daher gern zum Speichern von ergänzenden Angaben verwendet. Wenn da etwas unverständliches drin steht, dann ist nicht die Relation kaputt sondern nur die Ergänzungsangabe. Deshalb ist es nicht weiter schlimm, wenn da jemand als Rolle “forward:stop:17:alternate:summer” einträgt.
Ganz anders ist es in Relationen mit Rollenverwendung wie Abbiegerelationen oder PTv2-Relationen. Wenn man bei solchen Relationen die für bestimmte Zwecke festgelegten Rollen nicht benutzt, dann sollte man nicht mit einer Auswertung rechnen. Wenn jemand statt “via” in einer Abbiegerelation “viax” verwendet, dann fehlt das “via” und das ist ein Fehler. Genauso ist es in PTv2-Relationen. Die Objekte werden anhand ihrer Rollen erkannt und wenn da nicht die Rolle “platform” oder “platform_entry_only” oder “platform_exit_only” steht, dann ist es keine platform und wenn da nicht die Rolle “” steht, dann ist es kein Fahrweg.