PTNA - News: GTFS-Analyse

ach ja ein Link von der Trip-ID Seite zur Route-ID Seite wäre gut… Klick die machmal weg und dann steht ich da :confused: ( Und zu Übersichtseite von Route-ID auch )

“Alles machbar, Herr Nachbar!”

Das würde auch ein Problem lösen, dass ich derzeit nicht weiß, ob die angegeben Abfahrzeit irgendeine vom Tag, oder die erste vom Tag ist.
Die 5 (?) angegebenen Zeiten würde ich dann nach Uhrzeit aufsteigend sortieren und die Gesamtanzahl mit angeben.
Die Wochentage werde ich nicht mit rein nehmen, weil ich die “Mo,Tu,We,Th,Fr,Sa,Su” in den calendar.txt GTFS-Daten nicht auswerten will.
Codierung dauert 'ne Weile, Aggregation über DB muss dann neu gestartet werden, … neue Spalte(n) in die “trips” Tabelle rein

Geht schneller, mache ich jeweils oben in den

rein ("GTFS Analysen für <a …>DE-BY-MVV <a …>Linie “210”, Trip-Id = “10.T0.19-210-s20-1.4.H”).

Ja passt :slight_smile: Beim 463 werden einige Varianten nur einmal am Tag gefahren… da ist es halt besonders schwierieg… Als Fahrer des Busses muss ja des voll blöd sein immer verschiedene Routen einzuschlagen :confused:

ja perfekt :sunglasses:

so jetzt… hat mir Bildbearbeitung weiter geholfen… hab die trips sortiert nach den Haltestellen die sie anfahren bzw. nicht anfahren und gleiche bzw. teilrouten rausgelöscht bis nur noch die übrig geblieben sind die zu mappen sind… hab dann einzeln durchgestrichen die ich angeschaut hab, gefixt usw.

Komme aber jetzt nur auf 13 Relationen… k.A. warum jetzt nicht 14 :confused: …4 Relationen sind hinfällig… bzw. sind teilrouten hab ich gelöscht :slight_smile:

Gruß Miche

hab den Schlawiener :slight_smile:

Die Version fehlt noch:
https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=7.T0.19-463-s20-1.1.H

wie auch immer man es darstellt, als “druckbaren PDF”-Fahrplan oder hier in PTNA https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-BY-MVV&route_id=19-463-s20-1:

Es bleibt u.U. unübersichtlich, komplex, schwer umzusetzen.

Ich hab mich mal am Bus 446 probiert mit der Technik von Post #46. Hab für alle eine ID generiert… und geschaut ob sich aus GTFS und Relation paare sich bilden :). Über die Hälfte hatte auf Anhieb ein paar… dann hab ich mir die restlichen Relationen angeschaut und mit Plan verglichen… einige Fehler gefunden und nicht mehr vorhandene Fahrten. Für die geänderten Relationen eine neue ID erstellt… dann sind nur noch zwei Relationen übrig geblieben die ich neu erstellt hab :slight_smile:

Hätte nicht gemeint das es so gut geht mit meiner waghalsigen gerechneten ID :laughing: ( Es ist nur ein wenig aufwendig alle IDs zu erstellen… für alle GTFS trips und alle OSM Relationen )

Gruß Miche

Kleine Anmerkung in Sachen verdrehte Bachstuben… ähm Buchstaben…

Schreibt mal bitte beim VBB https://ptna.openstreetmap.de/results/DE/BE/DE-BE-VBB-Analysis.html Potsdam mit s und nicht mit z… Potsdam mit z zu schreiben, tut den Augen etwas weh…

Ansonsten… gab es nicht auch gtfs-Daten zu Buslinien in Brandenburg? …oder habe ich in der Auswertung nur zu flüchtig geschaut?

Sven

Potsblits - diese Buchstabenvertauscher!
SCNR

“Mea culpa” oder so ähnlich zum Punkt 1.

Zu Punkt 2: Die Struktur der Auswertung stammt von mir und ist unter https://wiki.openstreetmap.org/wiki/Verkehrsverbund_Berlin-Brandenburg/Analyse/DE-BE-VBB-Routes im OSM-Wiki zu finden - kann entsprechend von jedem (orts-)kundigen angepasst werden - was ich mir auch wünschen würde.

Kann sein, dass die “fehlenden” Busse aus Brandenburg unter Abschnitt 2.7.3 (https://ptna.openstreetmap.de/results/DE/BE/DE-BE-VBB-Analysis.html#A2.7.3) oder Abschnitt 4.3 (https://ptna.openstreetmap.de/results/DE/BE/DE-BE-VBB-Analysis.html#A4.3) zu finden sind.

Ich habe angefangen nach Städten zu sortieren, genauer gesagt nach ‘Operator’, bei denen sich die Stadt herleiten ließ.
Da sind unter 2.7.3 sicherlich auch Operator-Werte wie ‘Regionale Verkehrsgesellschaft Dahme-Spreewald mbH’, ‘Uckermärkische Verkehrsgesellschaft mbH’, ‘Busverkehr Oder-Spree GmbH’ und ‘Havelbus Verkehrsgesellschaft mbH’ bei denen ich mich hier von München aus schwer tue diese einem Ort oder so zuzuordnen.

Wie oben gesagt: … im OSM-Wiki zu finden - kann entsprechend von jedem (orts-)kundigen angepasst werden.

Toni

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