Mappen von ÖPNV vereinfachen

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.

Hi,

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...

Weide

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.

Tordanik wrote:

Natürlich ist das erstmalige Mappen von ÖPNV-Routen aufwendig, aber mich stört deutlich mehr der spätere Pflegeaufwand.

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?

Weide

Weide wrote:

Tordanik wrote:

Natürlich ist das erstmalige Mappen von ÖPNV-Routen aufwendig, aber mich stört deutlich mehr der spätere Pflegeaufwand.

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?

Weide

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.

viw wrote:

Wenn da jetzt 20 Wege übereinanderliegen?

Vermutlich nur ein zusätzlicher.

viw wrote:

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.

Weide

Weide wrote:

und die Quersplitterei der "Anderen" z.B. wegen Geschwindigkeitsbegrenzungen würde die ÖPNV-Linien nicht kaputtmachen.

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.

rayquaza wrote:

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.

Weide wrote:

rayquaza wrote:

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.)

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.

Weide wrote:

viw wrote:

Wenn da jetzt 20 Wege übereinanderliegen?

Vermutlich nur ein zusätzlicher.

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?

Oli-Wan wrote:

Doch, auch Potlatch übernimmt mittlerweile beim Aufspalten eines Weges beide Teile in die jeweiligen Relationen, inzwischen sogar in der richtigen Reihenfolge

Wow.

Aber das geht ja nur, wenn man die in der Relation benachbarten Wege hat. Wenn er die auch noch automatisch läd, dann wäre ja weiter als der JOSM.

Weide

Hallo

Ö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.

Edbert (EvanE)

viw wrote:

Wenn ich das richtig verstehe möchtest du dann für ÖPNV einen neuen Streckentyp haben, welcher über bestehenden Strecken liegt.

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.

viw wrote:

Wo liegt die Erleichterung?

Das Quersplitten der Straßen würde die Busroute nicht betreffen und das Quersplitten dieser Ways würde die Straßen nicht mehr betreffen.

Weide

EvanE wrote:

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.

Ja, vermutlich bringt es mehr Probleme als Vorteile.

Weide

Weide wrote:

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.

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.

rayquaza wrote:

Zum dritten Teil: Das korrekte Aufteilen von Ways sollte auch für Bots zumutbar sein.

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.

rayquaza wrote:

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.

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.

rayquaza wrote:

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.

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.

rayquaza wrote:

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.

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.

errt wrote:

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.

Erstens hätte man dann keine Vereinfachung für die vielen Nutzer anderer Editoren. Die Vereinfachung für die JOSM nutzenden Profis, denen dann aber inbesondere in den ländlichen Regionen die Ortskenntnis fehlen dürfte, ist wohl weniger wichtig, als eine Vereinfachung für die vielen Mapper vor Ort.

Eine weitere Schwierigkeit wäre, dass der Editor ggf. nicht alle Daten geladen hat, die zum Routing erforderlich sind. Insbesonder bei langen Routen dürfte es eventuell auch nicht möglich sein, diese Daten zu laden.

Es würde jedem Editor natürlich offenstehen, die Bot-Funktionen so weit wie möglich direkt zu implementieren und somit einen zusätzlichen Edit durch den Bot überflüssig zu machen.

errt wrote:

Außerdem muss man sich nicht mit der Mechanical Edit Policy rumschlagen.

Wieso man die Mechanical Edit Policy hier offenbar beliebig ignorieren kann, wenn man seinen Bot als Editor bezeichnet, ist mir ohnehin unverständlich.

slhh wrote:

Erstens hätte man dann keine Vereinfachung für die vielen Nutzer anderer Editoren.

Und wie viele von den vielen Nutzern anderer Editoren kümmern sich wohl um ÖPNV-Relationen? Klar, Potlatch hat dreimal so viele Nutzer wie JOSM, aber mit JOSM werden dreimal so viele Daten bearbeitet. Der Großteil der Potlatch-Nutzer sind Klein- und Kleinstmapper, von denen viele nicht einmal wissen dürften, daß es sowas wie ÖPNV in OSM gibt. Der aufsteigende Stern am OSM-Editorenhimmel, iD, liegt zwar nach Nutzern gleichauf mit JOSM - versteckt Relationen vor diesen aber gleich völlig. Alle weiteren Editoren kann man gleich vernachlässigen, deren Nutzerzahl ist jeweils mindestens einen Faktor 10 kleiner als die von JOSM; und mit einem Editor auf dem Mobiltelefon möchte man auch wirklich keine Routenrelationen bearbeiten.

slhh wrote:

errt wrote:

Außerdem muss man sich nicht mit der Mechanical Edit Policy rumschlagen.

Wieso man die Mechanical Edit Policy hier offenbar beliebig ignorieren kann, wenn man seinen Bot als Editor bezeichnet, ist mir ohnehin unverständlich.

Weil sie auf sorgfältige Bearbeitungen unter Einsatz von Editor und Plugins schlicht keine Anwendung findet:

... if you check each individual action caused by this ...

Tordanik wrote:

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 vorgeschlagene Bot-Lösung zielt keinesfalls primär auf die Ersterstellung ab. Für die Nutzer einfacher Editoren soll sie zwar eine gewisse Vereinfachung der Ersterstellung bringen, für JOSM Nutzer sehe ich den Hauptvorteil in der Pflege.

Die Expansion durch den Bot ist nur temporär bis zum nächsten Routing. Dazu wird die Auto-Rolle verwendet.
Nur wenn der Mapper diese manuell entfernt, würde die Expansion permanent. Deshalb sollte der Mapper dies nur in wirklich nötigen Fällen machen. Insbesondere wenn autoroute=template verwendet wird, kann man es vermutlich zumeist vollständig bei der Auto-Rolle belassen.

Der Bot würde vorhandene Auto-Member ignorieren und bei erfolgreichem Routingversuch durch neuberechnete Auto-Member erseten. Geht eine Route durch Probleme mit Auto-Membern kaputt, kann der Bot die Route selbständig reparieren.

Die meisten Sachen hat Oli-Wan ja schon kommentiert (danke, Oli), aber zwei Kommentare noch von mir:
1. Wäre das eine Möglichkeit für ein proof-of-concept. Wenn man hinterher einen Bot auf die Datenbank loslassen will, sollte man das ganze ja wohl mal getestet haben, und dafür würde sich das vielleicht anbeiten. Zumal es AFAIR schon ein Routing-Plugin für JOSM gibt, das mit etwas Glück für diesen Zweck erweitert werden könnte.
2. Sicher kann ich nicht einfach halb Deutschland lokal in meinen JOSM laden dafür. Die meisten Buslinien decken aber zumindest nicht so viel Fläche ab und bei Bahnlinien kann ich mich vielleicht auf das Nachladen von railway Objekten beschränken, so dass ich das grundsätzlich für denkbar halte.

errt wrote:

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.

Die Idee finde ich hervorragend!

Oli-Wan wrote:

Der aufsteigende Stern am OSM-Editorenhimmel, iD, liegt zwar nach Nutzern gleichauf mit JOSM - versteckt Relationen vor diesen aber gleich völlig.

1.1.0 RC1 ist schon da, sollte also nicht mehr so lange dauern, bis die Version 1.1.0 verfügbar ist.

Gruß,
Mondschein

errt wrote:

Sicher kann ich nicht einfach halb Deutschland lokal in meinen JOSM laden dafür. Die meisten Buslinien decken aber zumindest nicht so viel Fläche ab...

... und falls jetzt jemand ein Gegenbeispiel präsentiert: man kann ja immer noch abschnittsweise arbeiten: Die bisher vorhandene Route samt ihrer Mitglieder komplett laden, dazu nur die für den nächsten Abschnitt benötigte Umgebung. Oder mit der Bereinigen-Funktion Platz im Editor(speicher) schaffen (Landflächen, Gebäude usw. weg).

errt wrote:

1. Wäre das eine Möglichkeit für ein proof-of-concept. Wenn man hinterher einen Bot auf die Datenbank loslassen will, sollte man das ganze ja wohl mal getestet haben, und dafür würde sich das vielleicht anbeiten. Zumal es AFAIR schon ein Routing-Plugin für JOSM gibt, das mit etwas Glück für diesen Zweck erweitert werden könnte.

Das dürfte dann aber doppelten Entwicklungs- und Testaufwand bedeuten. Den Bot kann man bei Bedarf auch ohne die normale Datenbank testen.

Man sollte sich also wohl besser vorab für die Plugin oder die Botvariante entscheiden. Ich denke, für eine Plugin-Variante würde man das Konzept auch noch speziell darauf anpassen.

Die entscheidende Frage ist, ob man wirklich nur JOSM unterstützen muss, weil sich die anderen Editoren ohnehin nicht eignen.

Routen als zusätzliche OSM-Wege zu zeichnen, könnte die Erstellung insbesondere bei einfachen Editoren vereinfachen.

Mit einem für die überlagerten Linien optimierten Editor, solllte dies auch bearbeitbar sein. Solange aber auch nur ein nichtoptimierter Editor gebräuchlich ist, würden dessen Zerstörungen die Wartbarkeit katastrophal werden lassen.

Dennoch könnte man solche Wege als temporäre Eingabelösung insbesondere für einfache Editoren nutzen.
Wird ein solcher Weg gezeichnet und mit Rolle add einer Routenrelation hinzugefügt, so könnte ein Bot die überlagerten Straßenelemente heraussuchen, bei Bedarf splitten und der Relation hinzufügen. Den OSM-Weg würde der Bot anschließend löschen.

slhh wrote:

Dennoch könnte man solche Wege als temporäre Eingabelösung insbesondere für einfache Editoren nutzen.
Wird ein solcher Weg gezeichnet und mit Rolle add einer Routenrelation hinzugefügt, so könnte ein Bot die überlagerten Straßenelemente heraussuchen, bei Bedarf splitten und der Relation hinzufügen. Den OSM-Weg würde der Bot anschließend löschen.

Ich denke wenn es hilft, dann sollte man die "neuen" Wege als temporäre Eingabehilfe verwenden. Das geht wieder entweder als Plugin oder mit dem Bot. Der Bot wäre die universellere Lösung, da alle Editoren davon profitieren, aber er verdoppelt eben auch das Datenvolumen. Als Plugin hat man als Bearbeiter immer schon das fertige Ergebnis vor Augen und kann vor dem Hochladen noch eingreifen. Außerdem trägt man selbst die Verantwortung und nicht nur der Ersteller Betreiber des Bots.
Das Plugin für die Wegumwandlung ist vielleicht auch für andere Relationen interessant. (Wanderwege und Co)

Nur mal so am Rande: ist die tatsächlich gefahrene Route wirklich relevant? Üblicherweise kann man sowieso nur an Haltestellen ein- und aussteigen, ob zwischen diesen beiden Punkten jetzt Route A oder Route B gefahren wird ist für den Busreisenden wahrscheinlich eher nebensächlich.

RvdtG wrote:

Nur mal so am Rande: ist die tatsächlich gefahrene Route wirklich relevant?

Ja, z.B. weil man mit dieser über die aktuelle Position des Fahrzeugs Fahrplanabweichungen besser ermitteln kann als nur mit bestimmten Messpunkten (=Haltestellen).

RvdtG wrote:

Nur mal so am Rande: ist die tatsächlich gefahrene Route wirklich relevant? Üblicherweise kann man sowieso nur an Haltestellen ein- und aussteigen, ob zwischen diesen beiden Punkten jetzt Route A oder Route B gefahren wird ist für den Busreisenden wahrscheinlich eher nebensächlich.

Es kommt immer darauf an wofür man die Daten verwenden möchte. Wenn man nur wissen möchte wie man von A nach B kommt reicht dein Ansatz sicherlich aus. Aber schon wenn ich an einer Strecke stehe und mich frage welchen Bus habe ich gesehen? Oder mit welchem Bus kann ich an dieser Sehenswürdigkeit vorbei fahren.
Aber auch andere Dinge könnte eine Rolle spielen. Welche Straßen sind jetzt besonders ruhig? Oder wo ist mit Verkehrsbehinderungen zu rechnen? ÖV ist ja oft Pulkführer.

Oder wenn Linien es ermöglichen, dass einen der Busfahrer irgendwo auf der Strecke rauslässt. Bei uns vielleicht nicht so üblich, im Rest der Welt solls das aber geben 😉

Aachener Verkehrsverbund wrote:

Wenn Sie außerhalb des Alleenrings ab 20 Uhr zwischen den Haltestellen aussteigen wollen, so bitten Sie den Fahrer bzw. die Fahrerin beim Einsteigen, dass er/sie darauf achten soll, falls die Verkehrslage es zulässt.

Gibt's also auch hierzulande.

RvdtG wrote:

Nur mal so am Rande: ist die tatsächlich gefahrene Route wirklich relevant?

Schon um die Linie zu rendern,braucht man den Fahrweg. Direkte Linien zwischen den Halststellen würden auf der Karte sehr unschön aussehen, sofern es sich nicht nur um einem schematischen Netzplan handelt.

Weitere Anwendung: Wo wird wegen des Busverkehrs im Winter der Schnee zuerst geräumt?

Für völlig übertrieben halte ich allerdings die mehrfache Fahrwegerfassung für alle Varianten einschließlich verkürzter Fahrten. Beim Erstellen ist dies durch Kopieren der Relation kein Problem und vermutlich eher einfacher als bei anderen Lösungen, bei der Pflege rächt es sich dann gewaltig und beim Erstellen ebenso, wenn man mit den Varianten nicht solange wartet, bis die Hauptlinie wirklich komplett ist.

Bei Bot basierten Routing würde man die Pflegeprobleme durch die Varianten deutlich reduzieren. Mapper könnten bei der Bearbeitung von Straßen die Routenzugehörigkeit von Wegen mit "auto"-Rolle einfach ignorieren, da der Bot die Probleme gleich wieder fixen würde.

Die Routing-Plugin-Lösung könnte dies nicht bieten, hätte aber klare Vorteile beim gezielten Bearbeiten der Routen-Relationen. Da dann aber die Beseitigung von Problemen nicht ohne zutun eines Mappers möglich ist,
sollten wir einen Weg finden, die redundante Fahrwegerfassung wegen Varianten zu beseitigen oder zumindest zu reduzieren.

Ich denke, dass dies zumindest soweit kompatibel möglich ist, dass vorhandene Daten weiterhin gültig bleiben. Da die Preferenz für das Routing hier eher bei einer Plugin-Lösung zu liegen scheint, werde ich in Kürze ein Konzept zur Redundanzvermeidung in einem neuen Thread zur Diskussion stellen.

slhh wrote:

RvdtG wrote:

Nur mal so am Rande: ist die tatsächlich gefahrene Route wirklich relevant?

Schon um die Linie zu rendern,braucht man den Fahrweg. Direkte Linien zwischen den Halststellen würden auf der Karte sehr unschön aussehen, sofern es sich nicht nur um einem schematischen Netzplan handelt.

Die diskutierten Varianten (Editor-Plugin, Bot, nur Haltestellen) unterscheiden sich hauptsächlich darin, wann das automatische Routing stattfindet.
Die resultierende Karte würde (fast) identisch ausfallen.

Weitere Anwendung: Wo wird wegen des Busverkehrs im Winter der Schnee zuerst geräumt?

Dafür reichen die bisherigen Daten kaum aus. Ein einmal täglich verkehrender Bus ist meist nicht von einer Hauptstrecke im 10 Minuten-Takt unterscheidbar.

Für völlig übertrieben halte ich allerdings die mehrfache Fahrwegerfassung für alle Varianten einschließlich verkürzter Fahrten.

Eine verkürzte Fahrtstrecke mag noch verzichtbar sein. Bei den typischen Überlandstrecken werden oft Streckenteile ausgelassen oder alternativ bedient. Wenn man dort nur einige Varianten erfasst, fehlen auch Elemente in der ÖPNV-Karte.
Wenn wir ein Datenmodell festlegen, das mehrere Streckenvarianten zusammenfasst, verzichten wir auf die Möglichkeiten, die eine Ergänzung von Betriebszeiten, Fahrthäufigkeit oder eine Liste der Startzeiten bietet (Fußgängerrouting, Karten mit Fahrtdichtedarstellung).

Bei Bot basierten Routing würde man die Pflegeprobleme durch die Varianten deutlich reduzieren. Mapper könnten bei der Bearbeitung von Straßen die Routenzugehörigkeit von Wegen mit "auto"-Rolle einfach ignorieren, da der Bot die Probleme gleich wieder fixen würde.

Eine Haltepunkt-basierte Lösung wäre noch einfacher. Der Mapper würde bei der Bearbeitung von Straßen die Buslinien gar nicht sehen und könnte sich um die verbliebenen Relationen kümmern. Es würden auch temporär keine ungültigen Daten in der Datenbank stehen.

Die Routing-Plugin-Lösung könnte dies nicht bieten, hätte aber klare Vorteile beim gezielten Bearbeiten der Routen-Relationen. Da dann aber die Beseitigung von Problemen nicht ohne zutun eines Mappers möglich ist, sollten wir einen Weg finden, die redundante Fahrwegerfassung wegen Varianten zu beseitigen oder zumindest zu reduzieren.

Wie soll man die Varianten reduzieren? Durch Weglassen von Nebenvarianten oder durch Zusammenfassen mehrerer Varianten in einer (nicht mehr geordneten) Relation?

Ich finde es auch unschön, dass die Mapper damit in verschiedene Klassen geteilt werden. Mapper mit einfachen Editoren würden Straßen verbessern und Buslinien dabei (teilweise) zerstören, andere müssten daraus wieder gültige Daten machen.

Meines Erachtens wäre ein Datenmodell mit deutlich verringerter Komplexität (nur Haltestellen, in Ausnahmefällen via-Punkte) aber mit allen Varianten die bessere Alternative.