We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

ÖPNV-Mapping in OpenStreetMap

00:00

Formal Metadata

Title
ÖPNV-Mapping in OpenStreetMap
Subtitle
Geht das nicht einfacher?
Title of Series
Number of Parts
68
Author
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Linienverläufe und Haltestellen des öffentlichen Verkehr werden schon seit vielen Jahren in OpenStreetMap erfasst. In der letzten Zeit hat sich bei diesem Thema allerdings Ernüchterung breitgemacht. Einstige Mapper haben sich von diesem Themengebiet abgewendet oder beschränken sich nur noch auf die Haltestelleninfrastruktur. Neue Mapper werden von der Komplexität des Mappings abgeschreckt oder müssen zumindest eine hohe Einstiegshürde überwinden. Übriggeblieben ist daher nur ein Kern von wenigen Enthusiasten. Diese Situation stellt das OpenStreetMap-Projekt vor Probleme, denn flächendeckende, aktuelle und gepflegte ÖPNV-Daten lassen sich nur mit einer breiten Mapperbasis erreichen. Gleichzeitig ist OpenStreetMap aber eine der wenigen freien Quellen für Daten des öffentlichen Verkehrs, während die Verkehrsunternehmen in Deutschland bis auf Ausnahmen keine entsprechenden Daten bereitstellen. Die Gründe für den derzeit schlechten Stand des ÖPNV-Mappings in OpenStreetMap liegen jedoch auch in der Historie der verschiedenen Erfassungsschemata begründet. Mit der Zeit entstand eine Reihe unterschiedlicher Schemata, die bei vielen Mappern zu Verwirrung gesorgt haben, aber auch dazu geführt haben, dass in OpenStreetMap ÖPNV-Daten nach unterschiedlichen Schemata – teilweise auch als Mischformen – erfasst sind. Doch auch die Komplexität der Schemata selbst scheint viele Mapper zu überfordern, auch deshalb, weil die Dokumentation im Wiki veraltet, inkonsistent oder wenig anschaulich ist. Auch die mangelnde Auswertung durch Anwendungen ist eine Ursache dafür, dass kein großer Anreiz zum ÖPNV-Mapping besteht. Wenn Mapper das Ergebnis ihrer Arbeit nicht sehen und so auch kein Feedback darüber bekommen, ob die erfassten Daten korrekt sind, ist der Anreiz zur Erfassung bzw. Umstellung auf neuere Schemata relativ gering. Im Gegenteil verleiten Anwendungen durch mangelnde Unterstützung von neueren Schemata dazu, ältere Tags zu verwenden, damit die Daten visualisiert werden („Tagging für den Renderer“). Das Hauptproblem, das viele Mapper abschrecken dürfte, ist jedoch der hohe Aufwand zur Erfassung und Pflege der Daten. Gerade wenn eine ÖPNV-Linie über viele unterschiedliche Routenvarianten verfügt, steigt der Erfassungsaufwand und die Komplexität enorm an. Auch die Pflege der Daten ist nicht zu unterschätzen, schließlich ändert sich ein großer Teil der Daten mit jedem Fahrplanwechsel. In diesem Zusammenhang muss deshalb auch hinterfragt werden, ob und in welchem Detailgrad überhaupt ÖPNV-Daten in OpenStreetMap erfasst werden. Bei der Haltestelleninfrastruktur dürfte das relativ unstrittig sein, doch bei den Linienverläufen gibt es durchaus auch Argumente, die in Hinblick auf Aufwand und Nutzen gegen eine Erfassung sprechen.
Keywords
1
Thumbnail
13:04
24
39
58
59
Thumbnail
36:34
Texture mappingLecture/Conference
Computer scienceAtomic nucleusMAPPERLinieRollbewegungInterface (chemistry)Computing platformHöheAbstractionSpatial data infrastructureLinieDirection (geometry)Focus (optics)ClefNetzplanRollbewegungRouter (computing)Computing platformPositionBus (computing)MAPPERForestAbbildung <Physik>Atomic nucleusMoment (mathematics)Computer scienceEditorElectronic mailing listRoute of administrationBIENE <Computer>Software developerDOSComputer animation
AbstractionLinieRoutingVorverarbeitungImplementationInformationValidationData modelMAPPERData modelVorverarbeitungMassData qualityRouter (computing)Complete metric spaceGeodesicEditorRoutingMoment (mathematics)Route of administrationPlug-in (computing)ValidationLinieHalbautomatAbstractionBus (computing)Parameter (computer programming)InformationVideodatPopulation <Informatik>SurfaceGeometryGrand Unified TheoryCoroutineAgreeablenessComputing platformMobile appPlane (geometry)Open setPlanningSmart cardComputer animation
Route of administrationRouter (computing)Moment (mathematics)RoutingMAPPERRoundingInformationKantePlane (geometry)RALLY <Programm>Adaptive behaviorLinieGrand Unified TheoryXMLLecture/Conference
Transcript: German(auto-generated)
Willkommen zu meiner Präsentation über ÖPNV Mapping in OpenStreetMap und die Frage, ob man da manche Sachen nicht einfacher machen kann. Zuerst mal eine kleine Vorstellung zu mir. Bin seit 2008 bei OpenStreetMap aktiv, als User Rosy Katze bekannt und Gründer und Maintainer der Open Railway Map.
Da werden mich vielleicht einige von kennen. Ich bin seit den vergangenen drei Jahren Informatik studiert und bin aktuell Entwickler bei der Firma Geops in Freiburg, wo ich WebGIS-Anwendungen und Geodateninfrastrukturen entwickle, wo wir auch den Fokus auf öffentlichen Verkehr haben
und wo ich mich auch viel mit Fahrplandaten und Netzplänen und so Sachen beschäftige. Dann kurz zum Inhalt des Vortrags. Ich werde erst mal auf die aktuelle Situation des ÖPNV Mappings in OpenStreetMap eingehen.
Dann einen kleinen Überblick über die täglichen Schema geben, die sich da über die Zeit so entwickelt haben, für die, die da jetzt vielleicht nicht so drin sind, dass sie halt dem Vortrag dann auch folgen können. Dann auf Probleme mit dem aktuellen PT-V2 Schema eingehen und dann einige Anträge zu vorstellen,
wie man das vielleicht einfacher machen könnte, die ich mir überlegt habe oder die auch schon öfter in Mailinglisten und Foren mal aufgeworfen wurden. Am Schluss gibt es dann noch eine kleine Zusammenfassung und einen Ausblick und vorweg gesagt,
dass dem Vortrag schwerpunktmäßig um die ÖPNV Linien geht, jetzt weniger um die Haltestelleninfrastruktur. Es würde den Vortrag sprengen, wenn man jetzt auf beides eingehen würde. Die aktuelle Situation des ÖPNV Mappings in USM. Es gibt viele ÖPNV Mapper, die mittlerweile aufgegeben haben.
Das liest man halt immer so in Foren, also so sinngemäße Zitate, dass sich halt viele nur noch auf die Infrastruktur beschränken, weil die Erfassung von den Linien halt viel zu viel Aufwand bedeutet. Es gibt im Grunde momentan eigentlich nur noch so einen kleinen Kern von Enthusiasten, die da wirklich aktiv sind.
Da gibt es dann manchmal auch so sinngemäße Zitate nach dem Motto, ja eigentlich die Vernunft würde mir sagen, dass ich besser sein lasse, aber die Sucht ist dann doch stärker. Ja, ein Problem ist auch, dass die Einstiegshürde für neue Mapper relativ hoch ist.
Viele finden es toll, aber lassen dann doch lieber die Finger davon. Und das ist halt ein Problem, weil mit den wenigen ÖPNV Mappern ist es schwierig, die Daten halbwegs aktuell zu halten. Und gerade ÖPNV-Daten ändern sich halt ständig bei jedem Fahrplanwechsel und da muss man halt viel Aufwand investieren, um die aktuell zu halten.
Das Problem ist auch, dass die ÖPNV-Daten auch kaum genutzt werden, also speziell die Routenrelationen, dadurch sieht man halt relativ wenig von der Arbeit, die man da reinsteckt. Und man kann halt sagen, dass die ÖPNV-Daten im Moment bei USM dass das irgendwo ein Datenfriedhof ist. Also man hat halt viele alte Daten, also ich habe da Routenrelationen schon gesehen,
die irgendwie seit fünf Jahren irgendwie nicht mehr angefasst wurden, obwohl da zwischendrin schon zweimal irgendwie der Betreiber gewechselt hat und so Sachen. Viele Daten sind fehlerhaft und was halt auch ein Problem ist, dass es ein durcheinander verschiedener Schema gibt, die sich so über die Zeit entwickelt haben.
Wie würde ich mal kurz vorstellen, also es gibt halt einmal dieses PTV 1 genannte Schema, das ist so das allererste. Da wird halt einmal die Haltestelleninfrastruktur erfasst, da kommen diese bekannten Texte her wie Highway, Bus Stop oder Railway Platform. Und da wurden dann halt auch Routenrelationen eingeführt,
wobei bei den Relationen halt, also bei den Linien gibt es halt immer nur eine einzige Relation, wo alle Varianten drin sind. Das Ganze ist im Grunde einfach nur eine ungeordnete Liste der fahrenden Ways und mit forward, backward Rollen kann man halt festlegen, ob die jetzt nur für eine bestimmte Richtung genutzt werden.
Schema ist eigentlich ja mittlerweile ein bisschen veraltet, aber weiterhin noch verbreitet, weil es halt an vielen Stellen hat sich noch keiner die Mühe gemacht, das halt mal umzustellen. Dann gab es zwischenzeitlich mal das Oxomoa Schema, das ist 2009 bei einem Treffen deutscher Mapper entstanden in der Geofabrik, glaube ich.
Das ist eigentlich nicht mehr relevant heute, das hat sich nicht wirklich durchgesetzt, weil es relativ komplex war und dann durch das PTV 2 abgelöst wurde und viele Neuheiten, die mit diesem Oxomoa Schema eingeführt wurden, dann im Grunde bei dem PTV 2 dann teilweise in etwas vereinfachter Form wieder aufgegriffen.
Das PTV 2, das ist halt das aktuelle Schema, das ist 2011 entstanden. Da hat man dann einiges neu gemacht, also zum Beispiel einen neuen Key eingeführt, statt eben bisher diese separaten Texts für Highway, Bus Stop oder Railway Plattform.
Bei der Infrastruktur hat man dann einmal Stop Positions und Platforms. Stop Positions sind Notes auf dem Fahrweg, die beschreiben die Halteposition. Und die Platforms sind die Bussteige oder Bahnsteige neben dem Fahrweg.
Das kann man halt da in der Abbildung sehen, da sieht man halt so eine Straße, das ist eine typische Bushaltestelle, auf den Wegen die beiden Stop Positions und dann halt neben der Straße jeweils diese Platform. Bei den Routen hat man neu eingeführt, dass da einzelne Linienvarianten erfasst werden, also nicht wie bei dem PTV 1 halt alles in eine Relation werfen,
sondern halt jede Variante, die es bei einer Linie gibt, wird da separat erfasst, die man halt zuerst die Stops und Platforms in eine Relation aufführt und danach die Fahrwege, wobei da wichtig ist, dass die Reihenfolge beachtet wird und dass es keine Lücken gibt. Das kann man halt da gut sehen, das ist jetzt ein Screenshot aus JOSM, wo halt die Wege schön geordnet sind, wo es keine Lücken gibt.
Dann gibt es halt auch nochmal eine Route Master Relation, mit der dann diese ganzen Linienvarianten zusammengefasst werden und Stop Area Relation, die die Stop Positions und Platforms zusammenfassen. Das Problem bei PTV 2 sind halt irgendwo diese Routenvarianten,
also da habe ich mir bei ein paar Buslinien mal die Mühe gemacht, da wirklich alle Varianten zu erfassen. Das sieht jetzt auf dem Screenshot von der CART, also das mit Overpass Turbo erzeugt, da sieht es noch relativ übersichtlich aus, aber da hat man halt pro Richtung drei Varianten,
das ist jetzt hier dieser Bus 871, den man da sehen kann und das wird halt auch im Editor dann schon ein bisschen unübersichtlich, wenn man da halt wirklich jede Variante erfasst, wobei das halt noch vergleichsweise einfache Linien sind. Es gibt dann halt auch nochmal so Fahrpläne, da hat glaube ich kaum einer Lust drauf, da wirklich jede Variante einzutragen,
mal abgesehen halt vom Pflegeaufwand. Dann das Problem mit diesen Routenvarianten ist auch, dass die momentan eigentlich nicht wirklich ausgewertet werden, also es gibt zum Beispiel halt diese Open-PT-Map, die jetzt hier auf dem Screenshot zu sehen ist,
die zeigen aber einfach nur einen ganz einfachen Linienplan an und da sieht man halt nichts von dieser Arbeit, die man sich mit diesen einzelnen Linienvarianten gemacht hat. Deswegen ist die Motivation da auch relativ gering, da alle Varianten zu erfassen. Problem hat man auch bei besonders langen Routen,
also jetzt hier zum Beispiel der Euro City von Hamburg nach Zürich, da hat die Relation über 2200 Mitglieder, wovon halt nur 48 diese Stops und Plattforms sind. Das heißt, das andere sind halt alles Fahrwege und man muss praktisch im Editor, wenn man jetzt so eine Relation anlegt,
sich manuell von Hamburg bis Zürich dann durchklicken und in der richtigen Reihenfolge diese ganzen befahrenen Gleiststücke zusammenklicken. Das ist halt ein sehr hoher manueller Aufwand. Und vor allem das Problem dabei ist, dass die Hut-Relationen sehr schnell kaputt gehen können.
Also durch Bearbeitungen an diesen Fahrwegen kann es halt schnell passieren, dass dann in der Relation irgendwie die Elementreihenfolge auf einmal beschädigt ist oder dass es Lücken gibt. Und das schreckt halt auch Einsteiger ab, die jetzt vielleicht noch nichtmals diese ÖPNV-Relationen bearbeiten wollen, aber halt irgendwas an den Fahrweg ändern wollen und dadurch halt schnell was kaputt machen
und sich dadurch vielleicht dann nicht trauen, da irgendwas zu bearbeiten. Und vor allem kann man das eigentlich momentan nur mit JOSM sinnvoll bearbeiten. Also es gibt halt viele Editoren, die da vom Funktionsumfang her nicht ausreichen, um solche Routenrelationen sinnvoll zu bearbeiten,
was jetzt auch zum Beispiel diese Elementreihenfolge uns was betrifft. Genau, dann habe ich jetzt mal so ein paar Ideen gesammelt, wie man diese Routenrelation vielleicht einfacher erfassen und pflegen könnte. Da gibt es einmal immer wieder den Vorschlag, dass man Segmente anlegt.
Da würde man einzelne Teilstrecken im Grunde in Relationen zusammenfassen und diese eigentlichen Routenrelationen würden dann halt immer nur diese einzelnen Segmente referenzieren. Jetzt habe ich nochmal diesen Screenshot von vorhin genommen und da jetzt mal farbig so eingezeichnet, wie das dann aussehen würde.
Also da hätte man praktisch für jede Farbe so ein eigenes Segment und halt je nach Fahrtvariante würde man dann eben unterschiedliche Segmente da in diese Relation aufnehmen. Das Proposal ist von 2011. Da gab es auch immer mal wieder so Vorschläge, aber irgendwie ist das alles so ein bisschen eingeschlafen.
Ein großer Vorteil davon ist, dass man halt Redundanz vermeiden kann. Also bei einer Buslinie, wo man halt wirklich sehr viele Varianten hat, kann es halt passieren, dass so ein Wegstück in der Mitte teilweise dann irgendwie in 20 Buslinien Mitglied ist, was halt dann schnell unübersichtlich wird.
Und mit diesen Segmenten wäre dann dieser Way wirklich nur noch in einer Relation drin. Vor allem wären halt diese Segmente relativ kurz und einfacher zu pflegen und diese Abhängigkeiten wären weniger. Ein Nachteil von dieser ganzen Sache ist halt, dass man damit so eine zusätzliche Abstraktionsebene einführt.
Also man hat halt die Rays, die dann halt mit Relation zu Segmenten zusammengefasst werden, dann wiederum daraus diese einzelnen Varianten aufgebaut werden und dann halt mit dieser Route-Master-Relation vollständige Linien zusammengesetzt werden.
Und da kann man eigentlich annehmen, dass halt davon die viele Mapper eigentlich noch eher abgeschreckt würden, weil das halt schon relativ komplex ist, mal ganz zu schweigen von der Auswertung oder der Editor-Unterstützung. Andere Idee wäre noch, dass man Linienverläufe per Routing bestimmt.
Da würde man halt in den Routen-Relationen einfach nur noch diese Stop-Positions und Platforms aufnehmen in der richtigen Reihenfolge und mit Via-Punkten dann diesen genaueren Verlauf spezifizieren, indem man irgendwelche Kreuzungspunkte zum Beispiel angibt, die markant sind. Und dieser eigentliche Fahrtverlauf, den würde man halt rein über Routing bestimmen,
indem man halt immer von Stop-Position zu Stop-Position bzw. wenn da Via-Points sind, die dann noch beachtet. Vorteil davon wäre, dass man halt auch bei sehr langen Routen handliche Relationen hätte. Also zum Beispiel diese Euro-City von EIM, da hätte die Relation dann halt nur 48 Mitglieder statt 2200.
Das wäre halt dann relativ handlich. Und vor allem hätte man überhaupt keine Abhängigkeiten mehr zwischen den Fahrwegen und den Relationen. Das heißt, diese Beschädigungen bei den Bearbeitungen der Fahrtwege wären dann eigentlich fast ausgeschlossen. Und vor allem ist es auch relativ einfach in Editoren umsetzbar. Das wäre auch in mobilen Editoren einfach umsetzbar,
weil man im Grunde immer nur in den Relationen dieser einzelnen Stop-Positions und Platforms irgendwie hinzufügen müsste. Beispiel dafür ist Travic. Das ist ein Tool, was bei uns bei der Firma Geops entwickelt wurde im Rahmen einer Masterarbeit.
Das ist so ein ÖPNV-Tracker, wo man halt auf einer Karte live sieht, wo gerade welcher Bus oder Zug ist. Und das geschieht genau nach diesem Prinzip. Da nimmt man halt aus den Fahrplan-Daten die Informationen über diese Haltestellen abfolgen.
Und rutet dann im Grunde immer nur von Haltestelle zu Haltestelle. Das funktioniert auch insgesamt eigentlich ziemlich gut. Das Problem ist aber, wenn man das halt bei USM auch so machen würde, wäre halt immer eine Vorverarbeitung notwendig für jeden, der da irgendwie die Daten einsetzen möchte. Zum Beispiel irgendeinen Linienplan rendern.
Vor allem widerspricht es aber auch so ein bisschen diesen USM-Prinzipien, weil man diese Daten nicht manuell beeinflussen kann. Also man bestimmt dann halt diese Route per Routing, aber kann dann nicht genau sagen, ob das, was da jetzt rauskommt, jetzt wirklich stimmt.
Oder ob je nach Routing-Algorithmus da vielleicht Ergebnisse rauskommen, die jetzt nicht so ganz der Realität entsprechen. Und kann es natürlich auch nicht so gut manuell beeinflussen wie jetzt bei den klassischen Relationen. Deshalb wäre dann die Idee, ob man vielleicht so eine Art halbautomatisches Routing macht, wo man dieses Craftmapping mit Routing kombiniert.
Das wäre dann zum Beispiel als Plugin für JOSM denkbar, wo man dann eine Routenrelation im Grunde anlegen würde. Würde die Stop-Positions und Platforms reinnehmen, könnte dann sich diesen Routenverlauf routen lassen.
Und kann dann halt, also dieses Plugin in JOSM würde dann halt entsprechende Routenrelationen anlegen mit den Fahrtwegen. Und dann könnte dann aber immer noch manuell diese ganzen Sachen anpassen. Hätte eben damit weiterhin diese Qualität von handbearbeiteten Daten.
Vorteil von der Sache wäre, dass man gerade bei so langen Routen, dass das wirklich dann extrem schnell ginge, die anzulegen. Dass man eben nicht mehr dieses manuelle Zusammenklicken der Fahrtwege machen müsste. Und wie gesagt, dass man eben eine hohe Datenqualität hat, weil man die Daten manuell noch anpassen kann.
Nachteil bei der Sache ist aber, dass das eigentlich nur bei einer Neuerfassung hilft. Und man sonst im Grunde weiterhin immer noch diesen statisch fest in der Route vorhandenen Routenverlauf hat. Und es dadurch eben auch immer noch diese Beschädigungen bei Bearbeitungen gibt.
Deswegen könnte man auch auf die Idee kommen, ob man nicht vielleicht wieder zu PTV 1 zurückgeht. Also praktisch back to the roots, dass man eben keine einzelnen Linienvarianten erfasst. Sondern wieder dahin geht, dass man pro Linie einfach nur eine Relation anlegt, wo alle Varianten drin sind.
Hätte den Vorteil, da ist die Reihenfolge der Ways egal. Das heißt, da wäre schon mal ein geringeres Risiko, die Daten kaputt zu machen. Für Linienpläne, wie es sie aktuell bei USM gibt, wäre das auch völlig ausreichend. Das wäre relativ einfach zu erfassen. Und die Daten altern im Grunde auch nicht so schnell, weil eben nicht jede Variante erfasst wird.
Man kann eigentlich sagen, dass es vielleicht vom Aufwand und Nutzen her, wenn man das gegeneinander abwegt, dass es vielleicht ein guter Kompromiss wäre. Nachteil ist natürlich, man hat dadurch einen Informationsverlust gegenüber PTV 2, weil eben nicht mehr genau diese einzelnen Fahrtverläufe hat.
Was auch nicht so schön ist, das sieht man da halt. Diese PTV 1 Routen, die haben halt die Eigenschaft, dass die mal schnell so zerfetzt aussehen können. Weil eben da die Reihenfolge der Ways egal ist und eben wirklich alle Varianten aufgenommen werden. Das wird dann zum Bearbeiten auch schnell unübersichtlich.
Ja, das heißt, zusammenfassend kann man eigentlich sagen, um nochmal auf die Einstiegsfrage hinzukommen, geht es nicht einfacher. Was die Daten angeht, geht es nicht einfacher ohne Informationsverlust. Da muss man halt sagen, dass PTV 2 eigentlich schon das beste Abbild der Realität ist.
Erfassung und Pflege sind aber ziemlich aufwendig und PTV 1 wäre ein guter Kompromiss zwischen Aufwand und Nutzen. Bei den Editorien wäre eine Vereinfachung möglich, indem man, wie gesagt, den Mapper unterstützt durch Routing oder bessere Validierung.
Da gibt es eigentlich noch Ausbaubedarf im Moment. Und bei den Auswertungen wäre es auch hilfreich, wenn es eben Anwendungen gäbe, die zum Beispiel diese ganzen Linien, Varianten auswerten würden. Weil damit könnte man die Mapper motivieren, diese Daten auch wirklich zu erfassen. Weil was man halt auf einer Karte nicht sieht, das erfasst man auch nicht.
Und es könnte auch dazu zwingen, dass man eine einheitliche Erfassung mal vielleicht mit der Zeit hinbekommen würde und weg von diesem Durcheinander der verschiedenen Schemata. Als kleinen Ausblick könnte man noch die Frage stellen, welchen Maße man überhaupt bei USM ÖPNV erfassen sollte.
Also man kann halt fest sagen, dass offene Fahrplandaten weiterhin Mangelware sind. Und USM ist da wirklich die einzige Quelle im Moment für Haltestelleninfrastruktur.
Und gerade auch für diese Linienverläufe. Also selbst wenn Fahrplandaten offen gelegt werden, enthalten sie meistens halt wirklich nur diese reinen Fahrzeiten und keine geometriehende Linienverläufe. Das ist halt ein Alleinstellungsmerkmal für ein USM im Moment. Auch in der Hinsicht, dass man da ein weltweit einheitliches Datenmodell hat.
Das heißt, man kann halt die Frage stellen, welchem Maße ÖPNV denn überhaupt in USM erfasst werden sollte. Bei Haltestelleninfrastruktur, denke ich, kann man sagen, dass die eigentlich auf jeden Fall in USM gehört. Weil das halt auch klassische Geodaten sind. Wenn in Routenrelationen gibt es halt Argumente dafür und dagegen.
Dafür spricht halt, dass man damit Linienpläne erstellen kann und eine grobe Fahrtenplanung erstellen kann. Weil man eben weiß ungefähr, an welcher Stelle da welche Bus- oder Zuglinien fahren.
Gibt aber auch genügend Punkte, die dagegen sprechen. Weil der Nutzen von diesen Routenrelationen ohne echte Fahrplandaten ist halt relativ gering. Also niemand wird halt rein auf USM-Daten basierend irgendwie ÖPNV-Routing machen wollen. Also da wird man halt immer auf Fahrplandaten zurückgreifen.
Dann spricht halt auch noch dagegen dieser hohe Erfassungs- und Pflegeaufwand. Und dass die Daten sehr schnell veralten und dass man da eben nicht wirklich hinterherkommt, die zu pflegen. Und dass man eigentlich sagen kann, dass gerade auch bei diesen Linienvarianten, dass da der Nutzen im Keimenverhältnis zum Aufwand steht derzeit.
Ja, vielen Dank. Das war eine Punktlandung, wirklich auf die Sekunde. Wie die Eisenbahn. Wie die Eisenbahn, genau. Vielen Dank, Alexander. Wie die Eisenbahn.
Das wollte ich eben sagen. Fragen? Noch einen anderen Vorschlag zur, wie man sich das Leben da etwas leichter machen könnte vom Kosten-Nutzen-Verhältnis her.
Wie wäre es, wenn man sich einfach darauf beschränkt auf Varianten zu mappen, die, ich sag mal, mindestens entweder 50 mal am Tag oder 10 mal am Tag gefahren werden. Das eine wäre 20-Minuten-Takt, das andere wäre ungefähr einen Stundentakt. Weil da würde man meistens erstens die Linien erwischen, die interessant sind wirklich für Fahrgäste. Und zweitens auch, die ändern sich nicht so schnell und haben auch viel weniger Varianten.
Ja, das könnte man durchaus machen. Also viele von diesen Routenvarianten entstehen halt auch dadurch, dass es da irgendwelche Schulbuslinien gibt, die dann eben nur einmal am Tag da irgendeinen bestimmten Kurs fahren. Weil halt die Frage wäre, wo man da jetzt irgendeine Grenze festlegt. Also das wäre halt dann relativ willkürlich.
Da müsste man dann halt mal überlegen, was man als sinnvolles Kriterium wählen könnte. Meine Frage ist, ihr habt euch angeschaut, wie ihr das mit einem Routing-Algorithmus machen wollt. Das Problem ist, Busse fahren ganz oft nicht so, wie das Routing es will. Beziehungsweise gegen Einbahnstraßen, durch Bereiche, wo gar niemand fahren darf.
Es ist schwierig, das über einen Routing-Algorithmus zu machen, würde ich vermuten. Ja, das ist eben genau dieser Punkt, den ich da angesprochen habe. Ich dachte, dass Routing das zwar deutlich einfacher machen würde, aber dass insgesamt diese Verläufe wahrscheinlich auch gut passen würden.
Aber dass es dann in Details doch immer von der Realität abweicht und dass man eben bei so reinen Routing-Lösungen dann eben aber auch nicht mehr manuell da irgendwie eingreifen könnte. So, an der Stelle darf ich mal stillschweigend ein bisschen dienstliche Werbung machen, dass das gehen muss. Denn wir machen das mittlerweile für über den Daumen gepailt, deutschlandweit 80 Prozent der kommunalen Verkehrsbetriebe.
Die OSM-Daten zu nehmen und aufgrund der betriebsinternen Daten dann die Verläufe darauf zu routen. Also es geht sehr gut auf dem OSM-Netz zu routen. Was man allerdings nicht bekommt, im Gegensatz zu dem, was wir jetzt vermutet haben, dass es stabil ist gegenüber Änderungen.
Weil der Router ändert, gerade wenn man dynamisch routet, würde der Router einfach stillschweigend woanders lang routen. Wenn jemand da ein Gewicht drauf macht oder eine Tech-Änderung, die die Bewertung der Kante ändert. Also insofern, man kriegt dann auch eine Route. Aber tatsächlich würde ich sagen, für das Fehlerfinden ist es schwieriger mit dem Routen. Trotzdem praktikabel ist es im Moment mit den Daten, weil die OSM-Daten sich gar nicht so schnell verändern, wie man denkt.
Hatte ja auch Michael herausgefunden. Also bei Traffic hatten wir halt auch eigentlich immer ziemlich gute Ergebnisse bekommen. Aber wie gesagt, da wo man dann eben mal so Verläufe hat, die dann abweichen. Da ist es dann halt schwierig herauszufinden, woran das jetzt genau liegt und wie man das beeinflussen kann.
Ja, ich hätte drei Anmerkungen. Und zwar zu deinem manuellen Anfassen von den Routenrelationen, die dann der Router bestimmt. Wie stellst du dir das vor? Willst du da so Via-Notes mit aufnehmen in die Relation? Das wären dann halt einfach zum Beispiel jetzt bei Bussen irgendwelche Kreuzungspunkte, die Routenbestimmt sind.
Oder bei Eisenbahnen zum Beispiel dann Unterwegshalte, die jetzt keine Halte sind, aber wo der Zug halt lang fährt. Und die könnte man im Grunde mit so einer Rolle Via aufnehmen, um die halt beim Routing zu berücksichtigen. Ja, ich habe mit diesen Via-Notes meine persönlichen Bauchschmerzen.
Wenn ich mir jetzt eine Buslinie vorstelle, die über eine Straße führt. Und ein Mapper geht her und teilt die Straße in zwei Richtungsfahrbahnen auf, weil es eine Verkehrsinselin damit ergibt. Und der Via-Note landet auf der falschen Seite. Dann macht der Busrouter eine extra Runde um die Verkehrsinsel. Das führt dann zu etwas unschönen Ergebnissen.
Darf ich auch die anderen zwei Fragen noch stellen? Ja, wenn noch Zeit ist. Ja, das geht. Ich glaube, dass PTV 1 und PTV 2 nicht ersetzen kann, weil das einem OSM-Prinzip widerspricht. Wir tun ja normalerweise eigentlich nicht detaillierte Informationen durch gröbere Ersetzen. Wir schlagen ja auch nicht vor, das Voltage-Tag durch ein
Tag zu ersetzen, das nur noch Hochspannung, Mittelspannung und Niederspannung unterscheidet. Ja, wie gesagt, das PTV 1 wäre halt ein guter Kompromiss. Weil das für viele Anwendungen im Moment ausreichen würde und vom Pflegeaufwand deutlich einfacher ist.
Da wäre es halt ein guter Kompromiss zu diesem ganz detaillierten Erfassen bei PTV 2, weil die Daten nutzt im Moment eh keiner. Und ich würde da eher vorschlagen, dass man einen Expiry-Tag an den Rudenrelationen einführt, indem man sagt, das gilt für diese Fahrplanperiode und ab Fahrplanwechsel ist diese Relation veraltet. Ja, das habe ich schon privat beim ÖPNV-Mapping immer gemacht, dass ich dann so ein Timetable-Tag dran getaggt habe.
Oder dann als Wert dann immer diese Jahreszahl für den aktuellen Fahrplan. Dann kann man eben beim Fahrplanwechsel dann gute Qualitätskontrolle machen, an welchen Routen noch nicht überprüft wurden.