KVV ist auch bei PTNA-Analyse noch nicht drin, das kann ich nachholen.
VBB ist zwar drin, aber die Liste der erwarteten Linien ist so gut wie leer, d.h. derzeit nur eine IST-Analyse.
GTFS ist nicht gleich GTFS ist nicht gleich GTFS … jeder interpretiert den Standard wohl ein wenig anders.
GTFS-Aggregation für den VRR (Sqlite-DB 330 MB!) erstmal nach 6 Stunden Laufzeit abgebrochen, ein paar printf() eingebaut um zu sehen, ob der überhaupt was sinnvolles tut, neu gestartet.
Miche hat mir ein JavaScript geschickt, mit dem man Routen in GPX ausgeben kann …
Die Liste der existierenden Linien kann man ja für PTNA aus GTFS generieren, das mach’ ich dann auch mal …
AVV ist nun drin, aber ohne SPNV und noch ohne shapes
** SPNV scheint in GTFS nicht korrekt abgelegt zu sein, einige route_id in routes.txt gibt es doppelt (sollte UNIQUE sein)
VBB ist in Arbeit, Aggregierung wird wohl > 10 Stunden laufen: 1280 Routen, 203701 Trips
VRR ist in Arbeit, Aggregierung wird wohl ~ 10 Stunden laufen: 1825 Routen, 139344 Trips
KVV macht Probleme, routes.txt und trips.txt scheint mit dem Feld ‘route_id’ nicht zu klappen … ‘no such column’
*** Analyse implementiert: “welche Variante Teilroute welcher anderen Variante(n) ist.**”
Alles in Allem: GTFS ist nicht gleich GTFS ist nicht gleich GTFS … jeder Datensatz eines neuen Verbundes bringt wieder eine Überraschung mit sich.
Ufff aber das scheinen nicht so dicke Dinger wie VRR und VBB zu sein.
Als Nächstes will ich mich an die Shapes machen, denn die sind für OSM ja wichtig.
Sie beschreiben den exakten Fahrverlauf eines Busses, … mit allen Abzweigungen, Abbiegungen … und nicht nur die Haltestellen.
Ein “GPX-Download” soll draus werden, und evtl. auf einer Karte zeigen, …
Wenn shape Daten vorhanden sind, d.h. die Fahrtstrecke ist bekannt, so ist diese als Route in den GPX Daten enthalten. Die Way-Points sind die Haltestellen.
N.B.: Bitte beachten, dass die GTFS-Daten auch Fehler enthalten können, d.h. u.A. Positionen von Haltestellen stimmen nicht mit denen in OSM überein - warum auch immer.
GPX-Download : dieser Button erzeug eine GPX-Datei mit der Fahrstrecke des Busses, … wenn ‘shape’-Daten vorhanden sind, so entspricht das dem genauen Fahrweg und und nicht nur der Luftlinie zwischen den Haltestellen.
Download als CSV-Liste für PTNA : dieser Button erzeugt eine CSV-Liste als Input für de OSM-Analyse mit PTNA.
Den zweiten Punkt habe ich mit KVV durchgezogen, VBB steht noch aus.
Ich habe bewusst nur die Nummer der Haltestellen genommen, da das Bild sonst u.U. zu unübersichtlich wird. Ein Klick auf einen Marker zeigt zusätzlich den Namen der Haltestelle.
jetzt könnte man noch… für josm-Nutzer eine Overpass-Abfrage in die Hand drücken… um die Haltestellen herunter zu laden in einem schwung… so in der Art:
Gute Idee mit Overpass: evtl. weniger als 50m drumherum und wenn shape-Daten vorhanden, dann ebenfalls 1 - max. 2m um diese Punkte herum - was dann aber zu einer Mengenfrage, zu einem Problem der zu vielen Unterabfragen führen kann.
Eine Routingabfrage über alle Haltestellen: machbar, aber notwendig nur wenn keine shape-Daten vorhanden sind.
Ja den Abstand kann man auch kleiner machen… war nur zum testen
Anhand der Shape-Daten das auch zu machen… ist eine Wissenschaft für sich g… geht… aber
An Kreuzungen bekommt man viel beifang ab… abbiegende Wege usw. man kann das ganze auf den darauffolgenden Note filtern dann fällt viel beifang weg, aber dazu muss das shape gut mit dem aktuellen OSM Datenbestand zusammenpassen. Man kann aber auch vorher das shape nehmen und neu verrouten… also ersten und letzten Punkt nehmen und möglichst viele zwischen zwischenpunkte und damit Routing betreiben… dann hat man ein neues shape das besser mit osm zusammenpasst
aber das scheinen nicht so dicke Dinger wie VRR und VBB zu sein.
Stimmt der 262 hat nur 4 Varianten nicht 6 Varianten 