Das Erstellen und Pflegen der ÖPNV Routen ist ja schon sehr aufwendig, so dass eine Vereinfachung dringend nötig wäre.
In der Diskussion über den inzwischen zurückgezogenen ÖPNV Entwurf von Weide wurde u.a. vorgeschlagen, in den Routen nur noch die Haltestellen zu erfassen und den Fahrweg wegzulassen. Der Fahrweg wäre dann durch einen Router bei der Auswertung der Daten automatisch zu berechnen.
Einerseits ist dies eine sehr radikale Lösung, die sicher viele neue Probleme bringen würde, andererseits ist die mögliche Vereinfachung zu attraktiv, um nicht nochmal gründlich darüber nachzudenken.
Dies hat mich zu folgendem Konzept gebracht, dass auf einem Bot beruht, der den Mapper auf Anforderung unterstützt:
Der Mapper kann auf die Erfassung des Fahrwegs zunächst ganz oder in Teilen verzichten. Wird dann ein Tag autoroute=yes gesetzt und die Relation gespeichet, wird der Bot automatisch aktiviert. Dieser versucht anhand eines Routingalgorithmus aus den Haltestellen und eventuell bereits vorhandenen Fahrwegteilen den kompletten Fahrweg zu berechnen und die dazu benötigten OSM Wege an passender Stelle in die Relation einzufügen.
Um die automatisch eingefügten Wege unterscheiden zu können, soll eine neue Rolle “auto” verwendet werden, die von Auswertern einfach wie die leere Rolle zu behandeln ist. Der Bot hat bei einem erneuten Durchlauf allerdings “auto” Member als nicht vorhanden anzusehen.
Der Mapper hat die Möglichkeit, den automatisch gerouteten Fahrweg zu prüfen und bei Bedarf einzelne weitere OSMWege manuell quasi als via Punkte einzufügen. Als richtig erkannte Wege können optional durch löschen der Rolle “auto” auch in feste Vorgaben umgewandelt werden, wenn man in bestimmten Fällen eine unzureichende Stabilität des automatischen Routings befürchtet.
Dieses Konzept sollte sich weitgehend kompatibel in die bestehenden Datenstrukturen intergrieren lassen.
Vermutlich dürfte das automatische Routing bei Bussen problematischer als bei Schienenverkehr sein. Deshalb ergänzend folgender Vorschlag: Werden Routen als Member mit der Rolle “template” der Relation hinzugefügt, so hat der Bot bevorzugt Wege zu verwenden, die in einer dieser Template-Routen enthalten sind.
Wird statt des Tags autoroute=yes autoroute=template gesetzt, so hat der Bot zum Routing neben den bereits in ausschließlich Wege aus den Template-Relationen (neben den manuell eingetragenen Fahrwegabschnitten) zu verwenden. Als Template-Route bietet sich z.B. bei Varianten die Route der Hauptlinie an. Man mag dann ggf. immer noch einmal den Aufwand zur Erfassung und Pflege des Fahrwegs haben, muss dies dann aber nicht für jede Variante wiederholen.
Auswerter haben Member mit der Template-Rolle einfach zu ignorieren.
Eine Schwierigkeit könnte sein, dass die vorhandenen OSM Wege nicht für die Verwendung in der Route passend zerstückelt sind. Daher schlage ich vor, die bereits von Weide in seinem zurückgezogenem ÖPNV-Entwurf für die teilweise Verwendung eines Kreisverkehrs vorgeschlagene Rolle “part” auf Wege aller Art erweitert einzuführen. Um Probleme bei Teilung von Wegen zu vermeiden, muss die Definition der Rolle “part” nicht nur die teilweise Nutzung dieses Weges, sondern auch die Nichtnutzung zulassen.
Bei automatisch vom Bot eingefügten Wegen ist statt “part” “auto:part” zu verwenden, dass aber von Auswertern wie “part” zu behandeln ist.
Die Verwendung der Rolle “part” bzw. “auto:part” ist soweit zu beschränken, dass eine eindeutige Auswertung, welche Teile dieser OSM Wege tatsächlich zum Fahrweg gehören, möglich ist. Notfalls hat der Bot das Routing zu verweigern.
Dem Mapper steht ohnehin die Möglichkeit offen, manuell die OSM-Wege vorab geeignet zu splitten.
Zu den ersten beiden Postings meine ich, dass das in Ordnung wäre, wenn sich jemand findet, der das programmieren mag und vorher (!) eindeutig geklärt ist, wer schuld ist, wenn es dann doch nicht stimmt.
Zum dritten Teil: Das korrekte Aufteilen von Ways sollte auch für Bots zumutbar sein. Und wenn man sowieso Wege manuell splitten müsste (das, schon gesplittete Ways und taktlose Fahrpläne finde ich am nervigsten beim ÖPNV-Mapping) könnte man sie auch gleich in die Relation werfen.
Allgemein bleibe ich aber dabei, dass es sehr viele Buslinien gibt, deren Verlauf für einen Routingalgorythmus anhand von OSM-Daten nicht erkennbar ist, er aber zu falschen Ergebnissen kommen würde. Also müsste man eh nochmal alles genau nachprüfen (und die Rolle “auto” entfernen) – etwas was ich anstrengender finde als neu erfassen – und dafür auch wieder den Streckenverlauf kennen.
der Normalfall beim Mappen von Buslinien ist weder der Import noch der Mapper, der nach einer Tour eine komplette Haltestellenliste einer Linie hat. Der Normalfall ist, dass mehrere Mapper jeweils Teilstücke der Route und einige der dabei passierten Haltestellen erfassen. Dazu kommen dann noch ein paar Haltestellen, die von Mappern beim lokalen Erfassen hinzugefügt werden.
Die Haltestellenliste ist also normalerweise lückenhaft.
Routing macht – wenn überhaupt – erst dann Sinn, wenn die Haltestellenliste ziemlich komplett ist. Das wichtigste Hilfsmittel zum Füllen der Lücken ist aber die Route des Busses. Wenn der Bus einen Umweg macht, dann werden da wohl noch nicht erfasste Haltestellen sein…
Einfacher und wohl unproblematischer wäre, man würde das nicht durch einen Bot machen lassen, sondern beispielsweise als Editor-Plugin. Dann geht es zwar nur mit bestimmten Editoren, aber da es ja im Prinzip kompatibel zum aktuellen Schema ist, muss das ja nicht stören. So kann das lokal laufen, der Mapper kann das Ergebnis gleich betrachten und vor dem Hochladen ggf. nochmal korrigieren. Außerdem muss man sich nicht mit der Mechanical Edit Policy rumschlagen.
Ich finde das geht am Kernproblem vorbei. Natürlich ist das erstmalige Mappen von ÖPNV-Routen aufwendig, aber mich stört deutlich mehr der spätere Pflegeaufwand. Da läge für mich der Hauptvorteil punktbasierter Routen - und wenn ein Bot diese automatisch expandiert, geht dieser Vorteil natürlich verloren.
Die automatische Erstellung komplexer Datengebilde löst von daher nicht das längerfristige Problem der Wartung. Im Gegenteil wird das Problem womöglich sogar verschärft, weil es die Komplexität vor dem Ersteller verbirgt und so bedenkenlos noch mehr komplexe Strukturen eingetragen werden.
Mich auch, ich komme vor lauter Reparaturen kaum noch zum Mappen. Mal so ganz ungefiltert und undurchdacht: Was würde passieren, wenn für die Routen eigene Ways auf die Straßen gelegt würden statt die Straßen zu referenzieren?
Naja macht sich das dann wirklich einfacher? Wenn da jetzt 20 Wege übereinanderliegen?
Und würde das dann die Wartbarkeit wirklich erleichtern? Ich denke hier an Deutschlandweite ICE Verbindungen etc.
Bei eigener Fahrbahn/Gleisen sollte man es nicht tun – da hat man ja schon einen “eigenen” Way. Bei Buslinien würden die ÖPNVler nicht mehr die Straßen quer splitten und die Quersplitterei der “Anderen” z.B. wegen Geschwindigkeitsbegrenzungen würde die ÖPNV-Linien nicht kaputtmachen.
Das ist aber nur so eine spontane Idee, da können noch üble Haken drin stecken.
Wenn sich einfach alle daran halten würden, dass man bei sowas immer die Elternelement laden muss (was automatisch passiert, wenn man ein Gebiet lädt) würde das nicht passieren.
Beim Potlatch nützt das auch nichts. (Jedenfalls war das so, als ich es das letzte Mal probiert hatte.)
Bei JOSM sollte man nicht nachsehen, ob das Elternelement geladen ist, denn es geht eigentlich um die Kinder des Elternelements an (die geladen werden, wenn man das Elternelement explizit läd). Aber es reicht beim JOSM auch, eine beliebig kleine Umgebung jedes Endpunkts der zu splittenden Linie zu laden.
Beim ID vermute ich, dass es entsprechend zum JOSM ist – man also die Endpunkte der zu splittenden Linie mal im Bild gehabt haben muss.
Von den anderen ist mir nichts bekannt.
Weide
PS: Ausgenommen Kreisverkehre … die sind komplizierter.
Doch, auch Potlatch übernimmt mittlerweile beim Aufspalten eines Weges beide Teile in die jeweiligen Relationen, inzwischen sogar in der richtigen Reihenfolge. Routenrelationen macht er also nicht mehr kaputt, dafür nun aber Abbiegebeschränkungen.
Wenn ich das richtig verstehe möchtest du dann für ÖPNV einen neuen Streckentyp haben, welcher über bestehenden Strecken liegt.
Willst du das dann Verkehrssystemweise anlegen? Bus Straßenbahn etc. Oder soll es nur einen wegtyp ÖPNV geben? Wie soll das die Wartbarkeit verbessern? Wo liegt die Erleichterung?
Was passiert mit Eigenschaften des Weges? Werden Einbahnstraßen automatisch übernommen?
ÖPNV benutzt vorhandene Infrastruktur (Straßen bei Bussen, Schienen bei Tram und Eisenbahn).
Genau diese genutzte Infrastruktur sollte auch in die Routen-Relationen aufgenommen werden.
Nochmal einen weiteren OSM-Way über die vorhandene Ifrastruktur zu malen, verursacht nur neue Probleme:
Wohin kommen Taggs wie Maxspeed, Lanes usw. ?
Welcher der beiden übereinander liegenden OSM-Ways wird ggfs. geteilt?
Zuordnung zum falschen Weg sind bei übereinander liegenden OSM-Ways vorprogrammiert.
Das bringt nur Probleme, ohne das ÖPNV-Routing in irgend einer Weise zu verbessern.
Nein, ich dachte an Ways ganz ohne Tags, die mit den Straßen die Punkte teilen. Sobald man tatsächlich Eigenschaften der Straße braucht, muss man diese anhand der Punkte suchen. Ist vielleicht Müll … war nur ne Idee.
Das Quersplitten der Straßen würde die Busroute nicht betreffen und das Quersplitten dieser Ways würde die Straßen nicht mehr betreffen.
Und sobald man den Straßenverlauf ändern will (inklusive Einfügen von Knoten, Löschen von Teilen des Weges), muß man peinlich genau darauf achten, auch den Extraweg entsprechend zu bearbeiten. Die Handhabung im Editor wird schwieriger - mit JOSM vielleicht noch zu bewerkstelligen, mit weniger ausgefeilten Editoren sicher nicht. Und bei einer Erfassung von Routen als Weg wäre nicht erkennbar, an welcher von mehreren an derselben Straße nacheinander liegenden (Teil-)Haltestellen hält. Wie sollte man gar taggen, daß etwa ein “Schnellbus” an etlichen Haltestellen längs seines Fahrweges nicht hält?
Für mich überwiegen bei diesem Ansatz (neben den konzeptionellen Einwänden, vgl. Posting von Edbert) deutlich die Nachteile.
Für den Bot wäre das sicher zumutbar. Ich gehe jedoch davon aus, dass es zunächst aufgrund unzureichender vorgegebener Information zu fehlerhaften Routingversuchen kommt. Wenn der Bot bei jedem Fehlversuch gleich irgendwo die OSM-Wege zerstückelt, ist dies sicher kontraproduktiv.
Gilt dies auch für die Nutzer einfacher Editoren? Gilt das auch wenn mehrerere Wege schon unübersichtlich übereinanderliegen?
Ausserdem würde die Part-Rolle die möglichen Spits vermutlich auf Ausnahmefälle reduzieren.
Ohne einige Wege manuell als Via-Vorgaben einzufügen, ist das sicher richtig Dennoch wird es wohl viele Linienabschnitte geben, für die keine Via-Vorgaben nötig sind. Zumindest bei komplizierteren Verhältnissen würde ich bei Busse auch zu der Anwendung von autoroute=template neigen. Dies wäre aufgrund des Variantenreichtums von Buslinien immer noch eine Vereinfachung.
Die Kontrolle könnte rein graphisch erfolgen. Natürlich brauchen wir dazu ein Tool, dass die Strecke auf der Karte mit korrekter Berücksichtigung der part Rollen darstellt. Dass man nicht versehentlich den Fussweg oder eine Linie vom Landuse-Multipolygon erwischt hat, würde ja der Bot sicherstellen.