PTNA - News: GTFS-Analyse

Meine Signatur auf dem Smartphone:

“vom Smartphone gesendet, kann daher Tepfihler und Dank Autokorrektur auch mehr würzige Formulierungen enthalten.”

Hört sich gut an, ich verstehe hier aber nicht was mit ‘ID’ gemeint ist und wie die berechnet wird. Sind das die ‘gerundeten’ lat/lon-Dinger?

Den Post #46 habe ich - glaube ich - wohl verstanden.

Gruß
Toni

@Miche: BTW: zum Thema JOSM und Overpass-API und …

Ich hatte überlegt, aus einem JavaScript heraus ein Reihe von HTTP-GET localhost:8111/load_and_zoom… an JOSM zu senden (synchron) um so die engere Umgebung der Haltestellen in den JOSM zu laden.

Auch hier wieder eine Frage der Menge der Anfragen. Vor Allem, wenn man auf diese Weise noch alle, jeden 2. oder jeden 5. Shape-Punkt laden will.

Da überlastet man schnell mal das API und zwischen zwei GETs 100msec oder mehr zu warten verlangsamt das ganze zu sehr.

Hat irgendwer Erfahrungen mit solch einem Ansatz?

ja genau… also ich versuche über eine lat lon Liste… einen möglichst kurzen Wert du erhalten. Problem ich möchte GTFS und OSM vergleichen… die Haltestellen haben nur ungefähr eine ähnliche Position…

jetzt nimm ich einen vierstelligen lat und lon wert… und runde… ( Das Runden kann mal einen ausreißer verursachen :confused: wenn Gtfs auf und OSM z.B. abgerundet werden würde… aber wie oft kommt das vor… bei Bus 446 kein einziges mal… fehlt mir der erfahrungswert )

Andere methode die ich mir gedacht habe bis jetzt nur die erste lat lon vierstellig zu nehmen und dann nur die bewegungsrichtung (1-4 oder 1-8) pro Haltestelle zu nehmen aber wäre unschärfer aber… auch eine idee :wink: )

Bereichnung ist bis jetzt

x = runden(lat * 100; 0)

man könnte auch die eine zweite “id” machen mit einem anderen mulipikator um das runden Problem zu umgehen… und dadurch eine übereinstimmung finden

x = runden(lat * 120; 0 ) / 120 * 100

…ich kürze die Liste damit ab das ich den kleinsten lat bzw. lon von allen werten abziehe

Aber aber… man könnte auch alle genauen lat/lon in eine Liste ausgeben und dann wird das vergleichen halt aufwendiger… das man erst die anzahl der werte vergleicht und dann alle einzelwerte voneinander abzieht und die abweichung vergleicht…

nein sowas hab ich noch nicht gemacht… da müsste man mehrere URLs virtuell Klicken und dann werden viele Dinge geladen.

Ich mach eigentlich nur noch den Ansatz aus Post #45 … ich verroute die Punkte… lade ein gpx runter… erstelle dann aus dem gpx und den Punkte automatisch eine (riesige) Overpass Abfrage, wobei das ja keine Abfrage ist die öfters gemacht wird… sondern nur einmalig. In sofern hab ich da kein schlechtes Gewissen dabei. Da werden dann nur wenig zuviel geladen… muss nur beim teilen aufpassen, wenn notwendig… Dann geht alles sehr schnell :slight_smile:

Das Runden hier z.B.: fast ein Problem…

https://www.openstreetmap.org/node/562952831

lat: 48,1949448

hätte die Mvv hier: 49,195000 dann würde es anders gerundet, aber hat sie nicht :slight_smile:

lat: 48.1949190164032

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=22.T0.19-463-s20-1.7.H

Der Ansatz ist auch besser als 20-50 HTTP-GET Requests an JOSM zu senden … ohne Frage.

Das ‘riesige’ hatte mich aufgeschreckt und … ist die Overpass-Abfrage nicht ein GET, d.h. URL-encoded und somit von der Länge limitiert.
Oder kann man das auch per POST machen?

Dann hätten wie eine gute Lösung via Overpass-Query und JOSM und für z.B. 30 Stops und > 100 Shape-Punkte anwendbar.

aso… man kann mit josm die overpass Abfrage direkt ausführen… aber über HTTP-GET/POST Requests k.A. :confused:

ne schaut nicht so aus…

https://josm.openstreetmap.de/wiki/Help/RemoteControlCommands

…doch geht :sunglasses:

mit Overpass kann man Exportieren und da gibt es eine Möglichkeit, über import?url= :slight_smile:

http://127.0.0.1:8111/import?url=http%3A%2F%2Foverpass-api.de%2Fapi%2Finterpreter%3Fdata%3Dnode%255Bamenity%253Ddrinking_water%255D(41.88480278838879%252C12.481091022491455%252C41.89520166275077%252C12.50291347503662)%253Bout%2520meta%253B

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: