Die Nutzbarkeit… der z.B. Busrouten-Relationen oder Karten die daraus ist sehr beschränkt. Drum kommt auch oft die Sinnfrage auf: Warum die ganze Arbeit… wenn ich kaum nutzen davon habe.
Aktualität: Einmal angelegt dann nie wieder gepflegt/aktualisiert… Fehlen von neuen Haltestellen… Reihenfolge falsch… usw.
Lange Routen… oder viele Varianten: hier wird oft gar nicht gemappt…
Bei der Frage Mitarbeiter- oder Rechenkapazitäten: ÖPNV-Mapper gibt es zu wenige… mit tendez zu noch weniger… wenn man hier was erreichen möchte wird man erheblich vereinfachen müssen. Oder man sitzt irgendwann auf einem Berg überholter/unbrauchbarer Daten. Aber die kann man schön Rendern
Grundsätzlich sind die Routen schon ein OSM-Feature, dass ich sehr häufig nutze. Gerade in der Freizeit ist es sehr hilfreich zu wissen, wo welche Busse lang fahren. Ja, mittlerweile hat auch der Verkehrsverbund eine Interaktive Netzkarte aber damit kann ich mir z.B. nicht Busrouten und Wanderwege auf eine Karte legen, was für mich bei OSMAnd ein Killer-Feature ist. Damit habe ich schon vilele tolle Wanderungen mit dem ÖPNV überhaupt erst entdeckt. Oder Bus-Routen und Geocaches ist auch ne super Kombi.
Eine Auto-Routing Funktion für den Editor wäre durchaus hilfreich für das Mappen neuer routen und das wäre auch nicht auf eine Änderung im mapping-Schema oder sonst irgendwelche Konventionen angewiesen.
Diese Diskussion gab es ja an anderer Stelle auch in epischer Breite, dass für (angeblich) 95% der echten Anwendungen von ÖPNV-Mapping auch PTv1 reichen würde. Ist vielleicht nicht ganz von der Hand zu weisen. Mir fällt da nur OSMAnd ein, dass “echtes” Offline-ÖPNV Routing auf OSM-Daten macht, wobei ich keine Ahnung habe, wie das wirklich funktioniert und woher die z.B. die Fahrplanzeiten nehmen. Was PTv2 aber in jedem fall leichter macht ist die Qualitätskontrolle mithilfe der ofiziellen daten, da das sehr viel näher an GTFS ist. Meines erachtens ist das viel wert und sei es nur, dass das auch wieder nur indirekt dazu dient andere OSM-Sachen zu verifizieren.
Hab ich auch schon probiert… völlig unbrauchbar… Weil da was geschätzt wird, die Fahrplanzeiten fehlen einfach… Es wird einfach geschätzt wie oft der Bus fährt… auf dem Land um Stunden falsch… bzw unmöglich
Ich benutze OSMAnd übrigens auch um herauszufinden, an welchem Mast mein Bus wirklich hält. Das schafften andere Apps, die ich habe nicht, da sind Bushaltestellen immer punktförmig, auch wenn die in der Realität 12 Bussteige über hunderte Meter verteilt haben. Bei OSMAnd tappe ich einfach auf das Haltestellensymbol und da stehen dann alle Relationen z.b. die 2 nach Preußwald und die 7 nach Richterrich. Hier ist es dann auch tatsächlich hilfreich, wenn alle Kurzfahrten gemappt sind, denn nicht jeder Weiß z.B. das Richtung Preußwald die selbe ist wie Richtung Bushof.
Natürlich kann man aus OSM Daten auch was herauslesen. Aber irgendwo hinkommen möchte ich damit nicht. Dafür ist die App vom lokalen ÖPNV Anbieter besser, DB App oder Google Maps.
Sicherlich erwartet niemand das Osm die Verbindungsauskunft der Verkehrsuntetnehmen ersetzt, aber es ist eine gute Ergänzung. Weder die db-App noch google maps können etwas von den Dingen, die ich zuletzt ausgezählt habe.
Ja genau, das war der Hintergrund meiner Idee.
Diese Stützpunkte dienen ja der Arbeitserleichterung der Mapper. Als Mapper will ich net stupide Wegsegmente anklicken und sortieren (und dabei kleine 2-Node-Segmente suchen, die ich vergessen habe). Aber für die Datennutzer ist das ein riesen Ballast. Man würde so einen Datensatz nie mit minütlichen Diffs aktuell halten können.
Meine Idee ist quasi das beste aus beiden Welten. Die Route ist quasi aus Stützpunkten abgeleitet. Aber halt nicht dynamisch beim Anwender sondern statisch beim Mapper, wenn er was an einer Relation anpasst. Gleichzeitig ist die Route für alle anderen wie heute üblich dadurch durch Wegsegmente definiert. jOSM & Co können weiterhin die Relation bearbeiten/anpassen, wenn mal jemand einen Weg teilt verbindet, usw. Renderer können weiterhin stupide Segmente malen. Jeder KANN natürlich auch dynamisch routen. Wenn ich ÖPNV-Routing betreiben würde, brauche ich ja net die Segmente, sondern nur die Stützpunkte von Einstieg bis Ausstieg der Route.
Gar nicht, sie Routen von Haltestelle zu Haltestelle mit einem Bus-Profil etc. Ich finde das aber trotzdem hilfreich zu haben, auch wenn hier Google dank Echtzeitdaten natürlich weit überlegen ist.
Ich hab mir das jetzt auch noch mal angesehen. Es ist ne nette Spielerei und sicherlich beeindruckend, was die aus den Daten raus holen und auch zu Diagnosezwecken hilfreich. Als Verbindungsauskunft würde ich das aber auch zu 99% als untauglich sehen. Umsteigeverbindungen scheint der generell nicht zu finden und es ist auch nicht hilfreich, wenn ich jetzt nach Würselen will und der Vorschlägt den Nachtbus zu nehmen. Grundsätzlich bieten die OSM-Daten viele Möglichkeiten die die Verkederhrsbetriebe selber nicht anbieten, wie Verknüpfung mit anderen Daten, komplette Flexibilität im Vor- und Nachlauf, Indoor-Routing, echtes barrierefreies Routing usw. da bietet Mantis und Transitious einen netten Vorgeschmack drauf. Die nehmen für das eigentliche ÖPNV-Verbindung auch die GTFS-Daten von den Verkehrsbetrieben und von OSM “nur” die Haltestelleninfrastruktur.
Umsteigen sollte klappen, kann aber sein, dass es nur Umsteigen an der gleichen Haltestelle unterstützt und nicht laufen, Bus fahren, laufen, nochmal Bus fahren, laufen.
Ich habe es damals in einer Metropole genutzt, wo die Metro oder der Bus alle 3-10min kommt. Die Metro ist immer recht schlecht weg gekommen, weil er die nicht mit 120kmh geroutet hat und der Bus war immer zu schnell, weil der Stau gefehlt hat. Aber um zu schauen, mit welcher Kombination ich ans Ziel komme war es hilfreich.
Außerdem hab ich mal probiert… Eine GTFS Trip mit OSM Daten zu korrigieren… also die “WPT” auf die Position von der Platform… und “RTE” also Route Vektoren… auf die Stop-Positionen… anhand von dem eingetragenen ref:IFOPT
Ich nehme an, dass der zugrundeliegende brouter gar kein spezielles Routing für ÖPNV-Verkehr hat und das Ganze somit wirklich nur ein halber POC ist. Definitiv interessant, aber wir sind leider schon längst komplett off-topic und sollten vielleicht mal in einem separaten Thread Ideen sammeln, welche Ansätze es zum Vereinfachen des Mappens von Varianten des ÖPNV gibt und geben könnte, sonst wird das wieder Mal niemand finden
Die Nutzbarkeit hängt doch aber auch sehr davon ab, was du an Informationen erfasst. Du kannst das Intervall, Startzeit (Start erste Fahrt) und Endzeit (Start letzte Fahrt) der Routen angeben. Man kann sich dafür bestimmt auch komplexere Schemas ausdenken, sollte sich das Intervall ändern. Ist halt ein bissle auch ein Henne-Ei-Problem. Ohne solche Daten ist es schwer, einen Nutzen aus den Daten zu ziehen.
An sich empfinde ich PTv2 aber als wartungsfreundlicher als PTv1. Ich muss lediglich einen Routen-Ast verifizieren. Fährt der Bus da lang oder nicht. Bei PTv1 muss ich wissen, ob irgendeine der vielen Fahrten da lang fährt.
Da stellt sich mir aber auch die Frage, ob es den Aufwand wert ist. Ich sehe einen gewissen Nutzen darin, den Fahrtverlauf auf der Karte nachvollziehen zu können und das auch offline, aber zu versuchen den ganzen Fahrplan manuell nachzubauen in einem Datenformat, das dafür eher mäßig geeignet ist, sehe ich auch nicht so ganz. Wer ernsthaftes ÖPNV-Routing machen möchte, nimmt da besser die original Fahrplandaten, die für Deutschland frei und flächendeckend zur Verfügung stehen.
Das sehe ich teilweise auch so. PTv1 war gut, wenn man den Linenfahrplan z.B. als PDF vor Augen hatte und daraus die Fahrwege ableitete. PTv2 ist sehr viel näher daran, was die Verkehrsunternehmen selber an Daten liefern und daher sehr viel besser für den automatischen oder halbautomatischen Abgleich geeignet. Das halte ich für zunehmend entscheidend.
