PTNA - News: GTFS-Analyse

Genau das ist das Problem: wie lang darf der String oben sein. 255 Byte, … 8K …? Denn das ist ja ein GET-request.

Es gibt Angaben, dass FF 8K (in der Adressleiste) unterstützt, dass einige Webserver (Apache, …?) auch 8K unterstützen.

Der String oben bedeutet ja, dass JOSM zunächst den Web-Server spielt, die URL (?url=…) aber eigentlich an overpass-api.de weitergibt.

Also bleibt JOSM und die Frage, ob JOSM POST requests akzeptiert - schon mal ein Schritt weiter. Denn dann könne die Queries wirklich “riesig” sein.

Kann ich ja mal ausprobieren.

Nope: “501 not implemented”

schade… dann braucht man doch einen manuellen Schritt :wink:

ich hab mich mal dem Bus 440 probiert… mit id zu vergleichen… läuft gut :slight_smile: ID erstellen hab ich ein wenig vereinfacht… aber ich mach immernoch fehler beim kopieren :roll_eyes:

https://greymiche.lima-city.de/440_bus.ods

(Gelb ist was kein paar gefunden hat… mehrere Tabellen! :slight_smile: )

Wie bereits geschrieben: JOSM akzeptiert kein POST.

Aber ich werde mich mal an die maximale akzeptierte Länge der Query ran tasten und einen Button auf der Seite machen, mit dem man sich (möglichst viele) kleine Umgebungen der Haltestellen und Shape-Punkte via Overpass in JOSM laden kann.

So nach dem Motto: 8K werden von JOSM akzeptiert, minus 500 byte Overpass-Drumherum = 7.5K.
Pro Punkt 75 byte macht ungefähr 100 Punkte, deren Umgebung man runter laden könnte.
Bei 20 Haltestellen und 400 Shape-Punkten wären das alle Haltestellen und jeden 5. Shape-Punkt … alles nur sehr grobe Schätzung.

… was mit einfällt: was nun kommt ist Blödsinn oder bietet zumindest keine brauchbare Lösung, habe ich beim Schreiben bemerkt

es gibt da in Excel ein Add-In (“Solver”, aber man muss ja auch nicht Excel nehmen), mit dem man bei gegebenen x,y-Werten (lat,lon) versuchen kann eine Formel zu erstellen, deren Graph möglichst nah an allen Punkten vorbei läuft - sprich: die Standardabweichung ist möglichst klein.

Im einfachsten Fall per Linearer Regression z.B. f(x) = 2 x + 3

oder sehr komplex z.B.: f(x) = 3 x4 - 5 x3 + 2 x**2 + 3 x + 3

und vergleichen kann, ob bei GTFS-Points und OSM-Points die selbe Funktion herauskommt.

… und nun gehen die Pferde mit mir durch … und werfen mich ab …

Hindernisse: das funktioniert nur, wenn sich der Bus irgendwie nur von West nach Ost bewegt, keine Schleifen bildet, …
Es sei denn, man sortiert die (lat/lon)-Paare streng nach aufsteigendem ‘lat’, wodurch man aber die Charakteristik der Buslinie (Reihenfolge der angefahrenen Haltestellen) komplett verändert und sich zwei Buslinien u.U. wiederum kaum von einander unterscheiden würden.

Na ja: wie gesagt Blödsinn oder im besten Fall keine Lösung.

Generell zum dem Thema: Ich hatte eher an Anzahl und ‘Name’ der Haltestellen gedacht: mit/ohne Ortsname, normalisiert (d.h. str. → straße), …

Ist fertig, ohne Limit auf 5, d.h. es werden alle angegeben.

Ich bin mit der Lösung aber nicht so recht glücklich, da die Zeit der Aggregierung (Vorbereitungsphase, bevor ich die Daten veröffentliche) nun beim MVV von 21 Min auf 41 Minuten gestiegen ist.

So weit so gut und nicht so tragisch.

Aber beim VBB dauert diese Phase derzeit schon 16 Stunden, dann 32 Stunden (?) ist schon recht viel - selbst wenn ich alle Schritte weiter automatisieren werde.

Hab ich schon gesehen… hab es gleich genutzt um die Uhrzeiten bei den zwei Relationen zu aktualisieren :slight_smile: Die Sekunden Angabe bräuchte ich nicht :wink:

Ja das ist schon krass :confused: …sind das so viel Daten :frowning:

Ja kann man auch probieren… aber alleine beim MVV gibts es schon viele kreative Abkürzungen :expressionless: … lat/lon sind mir die Namen erst einmal egal und sogar ungefähr die Position kontrolliert :wink:

ja es gibt mehr als einen Weg nach Rom :slight_smile: Meine Zielsetzung ein möglichst/relativ kleines Ergebnis was ich einfach vergleichen kann. Bis jetzt funktioniert es ganz gut :sunglasses: Hab jetzt noch kleine Verbesserungen an den zwei Seiten gemacht… um mir noch ein paar Klicks und Tastendrucke zu sparen :slight_smile:

Zu 1.) die Sekunden nehme ich noch raus. die Zeiten sind aber unabhängig davon ob nur Mo-Fr oder nur Sa+So oder jeden Tag … also ein wenig Vorsicht.

zu 2.) ja das sind 'ne Menge Daten, die bei der Aggragation wegfallen … nachdem ich erkannt habe, dass sie redundant sind: ein Bus, der alle 10 Minuten fährt von 04:48 bis 26:08 (02:08 des Folgetages) hat für jede Fahrt eine eigene Trip-ID und für jede Trip-ID gibt es eine Folge von Haltestelleneinträge (immer die gleiche), die angefahren werden und all diese Trip-IDs unterscheiden sich eigentlich nur bzgl. der Abfahrzeiten - für OSM eigentlich irrelevant. Da kann man eine Menge Holz vernichten.

zu 3.) Ja, das Kreativität bei den Namen ist grenzenlos. “Fürstenfeldb.” und Fürstenfeldbr." und “Höhenkirchen-S.”, “Höehenkirchen-Sie.”, “Höhenkirchen-Sieg.”. Bei einigen Dingen habe ich den Verdacht, dass hier auf Teufel-komm-raus versucht wird auf 16 Zeichen (oder so) zu reduzieren. lat/lon ist wohl die bessere Methode.

zu 4.) Da hast du Recht. Bei allem sollte im Hinterkopf bleiben, dass es einfach anzuwenden ist und Ausreißer möglichst erkannt werden und warum das ein Ausreißer ist, verständlich und nachvollziehbar bleibt.

hab was lustiges gefunden:

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=10.T4.19-413-s20-1.29.R
https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=16.T4.19-413-s20-1.30.R

Diese zwei Unterscheiden sich nur in Schlacht bei der Position lat/lon :laughing:

Jetzt Bus 413 :slight_smile:

Weiter verbessert :slight_smile: Meinen Relation zu GPX hab ich noch um ein paar rolen erweitern müssen :confused:
https://greymiche.lima-city.de/413_bus.ods

Gruß Miche

Wobei der obere rein fahr-technisch nicht passt, falsch ist?

Ja des glaub ich auch… Wäre ungeschickt…

Heute hab ich die erste Haltestelle ein Problem mit dem runden gehabt. Dort war die Platform weit hinter der der MVV, weil die Platform beim Schutzhäuschen gemappt war. Das Schutzhäuschen war weit weg von der Straße… jetzt hab ich einen shelter type => öpnv gemacht und die platform näher der Straße gebracht

Korrekt, und dann gibt’s noch andere Unterschiede:

  • Bus 210: Hst Ortsmitte (südwärts) und Robert-Koch-Straße (nördlich der Straße) wurden letztes Jahr umgebaut (verlegt: 30 - >50m), in den GTFS-Daten aber nicht angepasst
  • Busse in Starnberg: z.T. erhebliche Abstände zwischen dem was in OSM gemapped ist und dem was GTFS sagt (was ist richtig?)
    ** “Starnberg, Landratsamt” ist definitiv falsch in den GTFS (nicht mehr gepflegte und unvollständige Liste von Fehlern: https://wiki.openstreetmap.org/wiki/M%C3%BCnchen/Transportation/MVV-GTFS#Fehler_in_den_GTFS-Daten)

Die Analyse von Stops: OSM vs. GTFS ist eine anderes Thema, dem sich Dietmar (okilimu) widmen will. Das hatten wir auf dem Hack-Weekend in Karlsruhe im Februar mal so besprochen. Evtl. basiert das dann auf einem Ansatz von Holger von mfdz.de (https://mfdz.de/blog/haltestellendaten-bw-vergleich-osm-nvbw)

Gruß, Toni

ich noch eine gefunden die bei mvv nicht richtig ist: ( ca.75m falsch )

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=48.07524%2C11.88546%3B48.07502%2C11.88640#map=19/48.07518/11.88595

Bus 442 :slight_smile:

noch eine sehr falsch ist… die hab selbst mal korregiert in OSM ca. 50m Falsch

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=48.31500%2C11.92148%3B48.31459%2C11.92128#map=19/48.31478/11.92146

unter anderen Bus 501

Bzgl. der Stops ansich: ich werde mal mit Dietmar Kontakt aufnehmen.

Da braucht’s eine andere Art von Auswertung als bei den Routen:

  • Lage der Platform (OSM vs. GTFS)
  • Name der Platform (korrekte Schreibweise, ref_name, …)
  • IFOPT (sofern bekannt, beim MVV ist die stop_id = IFOPT, bei anderen nicht …)
  • was fehlt in OSM
  • was ist in OSM zu viel
  • welche sind PTv2-konform
  • was ist mit SEV, Schulbussen?

Holger von mfdz.de hat da ja eine Python-basierte Analyse, die man evtl. anpassen könnte.
Die Analyse hat Daten nicht von GTFS, sondern von NVBW, und die CSV-Daten sind umfangreicher pro Haltestelle.
Die Analyse macht von dem ‘mehr’ an Daten Gebrauch, kommt also evtl. mit "reinem " GTFS nicht zurecht / nicht sehr weit.

Oder das man das möglichst einfach dem MVV melden könnte und die das in ihren Daten ändern und dann beim nächsten Gtfs dann richtig wäre :confused:

… und die wiederum an Mentz DV, ihrem Dienstleister.