PTNA - News: GTFS-Analyse

Das wäre noch praktischer… aber kenne ich keinen der das macht…

Eins muss man noch aufpassen manche Router optimieren ihre Routen und lassen mache Punkte rausfallen… z.B. Graphhopper der optimiert ein wenig…

Hi Toni,

hab gerade mal eine Relation gemacht mit auf Grundlage von deiner GTFS-Analyse. Geht schon ganz gut :slight_smile: Was mir noch fehlt…wäre eine Tabelle mit den entsprechenden Tagging für die Relation, die ich dann mit Copy&Paste auf die Relation im JOSM übertragen kann :slight_smile: Also so eine Tabelle mit allen tags:

https://www.openstreetmap.org/relation/10981156

Gruß Miche

…und vielleicht auch noch für die Masterrelation…, weil sonst mach ich da zu viele Fehler :confused: :roll_eyes:

Edit:
…noch zwei Relationen
https://www.openstreetmap.org/relation/10981208 (Rückfahrt)
https://www.openstreetmap.org/relation/10981209 (Master)

dritte und vierte version :wink:
https://www.openstreetmap.org/relation/10981294
https://www.openstreetmap.org/relation/10981323

Hab jetzt die gpx-dateien mit meinen Ding da verroutet (Brouter + access Änderung)
https://greymiche.lima-city.de/bus-relation/GPX2Routing-request2/index.html

und ein Overpass-Abfrage erstellt:
https://greymiche.lima-city.de/bus-relation/GPX2Overpass-Queries/gpx2overpass7.html

und mit Josm geladen, gpx Dateien (haltestellen und routing ergebnis ) angehängt
https://greymiche.lima-city.de/bus-relation/GPX2Overpass-Queries/gpx2overpass7.html

( => bei edit in Josm muss man aufpassen wenn man Wege teilt muss immer der komplette Weg mit angrenzenden Wegen und Relationen geladen sein! Und relation-Fenster geschlossen! sonst andere Relationen ein wenig kaputt :wink: )

…jetzt noch was… bei https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=15.T0.19-262-s20-1.12.R ist die Fahrer Anweisung mit dem Wenden noch dabei, willst du die drin lassen?

Ich hab mich mal versucht den GTFS trip mit einer OSM-Relation zu vergleich bzw. zuzuordnen… in dem ich die Haltepunkt die lat/lon “verunschärfe” und runde auf eine vierstellige Zahl, um Abweichungen glatt zu bügeln… also aus 48.1752064111777;11.7630580897431 wird 4818;1176. Das ganz mit OSM-Relation und GTFS-Trip… dann noch ein wenig verkleinert die Ausgabe… (die kleinsten Wert von lat/lon abgezogen)… dann müsste bei beiden das gleiche raus kommen. :slight_smile:

- Relation zu GPX machen:
https://greymiche.lima-city.de/bus-relation/ptv2_platform_to_rte/index.html?relation=10981156

- GPX zu ID machen:
https://greymiche.lima-city.de/bus-relation/gpx2rel_id/index.html

Ist schon ganz gut, bis auf das wenden des Fahrers macht den unterschied: :confused:

minlat=4813&minlon=1170&lonlats=6,5;6,5;5,4;6,4;5,3;5,3;6,3;6,3;4,2;3,2;2,1;2,1;0,0;0,0;
minlat=4813&minlon=1170&lonlats=6,5;6,5;5,4;6,4;5,3;5,3;6,3;6,3;4,2;3,2;2,1;2,1;0,0;

Trip und Relation:
https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=15.T0.19-262-s20-1.12.R
https://www.openstreetmap.org/relation/10981156#map=14/48.1560/11.7335

Servus Miche,

nein, dass will ich noch “ausbügeln”, d.h. als PTNA Information ausgeben.

Das Problem gibt es scheinbar mehrfach, auch ‘mein’ 210er “leidet” in Brunnthal, Zusestraße darunter, siehe https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-BY-MVV&route_id=19-210-s20-1 .
Die beiden PTNA Infos dort sind von mir händisch eingetragen worden.
Den zweiten davon kann ich automatisch erkennen und als “zu prüfen” kommentieren. Der erste Fall ist ähnlich gelagert (Anweisung für Busfahrer des Verstärkerbusses, der abends nur in eine Richtung fährt). Dieser Fall ist schwer zu erkennen, eigentlich unmöglich.

Einen Trip definiere ich in PTNA durch einen String, der die Stop-IDs der Reihe nach enthält.

  • “stopid_1|stopid_2|stopid_3|…|stopid_n-1|stopid_n”

Auf diese Weise erkenne ich dann auch “Teilroute von” (= substring of) oder “identisch zu”

Das Problem des speziellen Wendens hier (“München Messestadt-Ost”, “Brunnthal, Zusestraße”, …) erkenne ich im Fall von Stop-ID == IFOPT … “stopid_n-1” nahezu gleich mit “stopid_n” bis auf den letzten Teil des IFOPT (den Steig).

Den Code habe ich schon anderswo, werde ihn aber noch in die Analyse der GFTS-Daten einbringen … bevor das Erkennen von “Teilroute von” ausgeführt wird.

Gruß
Toni

Oh je… eine Leerfahrt :confused: ja das kann man nicht erkennen… ist das nicht im GTFS irgendwie markiert, weil wenn jemand man dem GTFS routing machen will muss man ja diese fahrt ausschießen :confused:

… und andere Arbeiten an GTFS.

Warum mache ich mir die Mühe mit GTFS?

  • u.A. damit Mapper diese Informationen schneller, vorbereitet erhalten

  • aber auch, damit ich bei der eigentlichen PTNA-Analyse des OSM-Zustandes später mal auf diese Daten zugreifen kann:
    – haben wir in OSM so viele Varianten wie es in GTFS gibt?
    – sind die OSM-Varianten identisch/deckungsgleich mit den Trips in GTFS - bzgl. stops?
    – wie sieht es mit den Stop-Names in OSM versus GTFS aus …

Nun, meine Erfahrung ist, dass GTFS Daten bei Leibe nicht fehlerfrei sind - niemals nie nicht.

Daher der Versuch mit “PTNA Information zur Variante” hier einen Indikator einzubauen, dass hier was nicht stimmt.

Ursprünglich hatte ich daran gedacht, hier den Inhalt der “PTNA Informationen” von Mappern eintragen zu lassen …
Aber: die GTFS-Daten ändern sich zu häufig, und ich habe noch kein Konzept, die Mapper-Kommentare in die nächste GTFS-Version mit zu übernehmen.

Muss ja eigentlich nicht, denn der Fehler liegt in der Erzeugung des konkreten GTFS-Datensatzes aus dem internen Datenbestand (hier: des MVV), bei dem solche Fahranweisungen sehr wohl Sinn machen.

Den konkreten Fall habe ich letztens mal genauer analysiert, was die Abfahrzeiten der einzelne Trips angeht.
Die Leerfahrt existiert in den GTFS-Daten nur für solche Fahrten, wo der Bus die Strecke nochmals fahren muss und noch nicht ins Depot zurück kann.

Das trifft auch auf den anderen Fall zu, den bei “Brunnthal, Zusestraße” - wobei der Wendevorgang lustigerweise womöglich auf dem Hof des Depots https://www.openstreetmap.org/?mlat=48.03940&mlon=11.66590#map=17/48.03940/11.66590 stattfindet - der örtlichen Gegebenheiten wegen (oder auf dem Turningcircle vor “Metro” https://www.openstreetmap.org/?mlat=48.03961&mlon=11.66027#map=17/48.03961/11.66027).

ja für die Busfahrer… aber für die Kunden… ist das nicht wichtig. Aber bis jetzt mappen wir ja nach der Kundensicht :slight_smile: ich meinte auch Routing für den Kunden…

Des ist ja auch toll :slight_smile: Den Bus 262 konnte ich so sehr viel schneller eintragen :sunglasses:

ja das ist so der Punkt… bei 463 gab es kleinere Änderungen… aber welche Relation der 10-20 Relationen muss man da jetzt ändern :confused:

Gute Idee :D:cool: … alles was das Erstellen, Korrigieren, Verifizieren, … von Routen erleichtert.

Wenn ich nur wüsste, wie stabil die route_id und trip_id von Version zu Version der GTFS-Daten wären, oder ob sie sich jedes Mal ändern (nicht nur beim MVV).

Zumindest könnte man die trip_id in OSM als ‘ref_trips’ = <trip_id> mappen.

Ich habe das mal wie beschrieben implementiert:

und erst einmal für den MVV durchlaufen lassen - 80 mal fündig geworden.

Edit: bzw. 98 mal, wenn man die gesamte Haltestelle vergleicht. Nachtrag und Korrektur wegen Bus 221 und Endhaltestelle “Unterhaching” de:09184:2310:2:2 und de:09184:2310:1:1

Hi Miche,

ist fertig, auch für Route-Master.

Welche Tags würden dMn noch fehlen?

Gruß
Toni

Wenn ich das mit einer Relation vergleiche ist so ziemlich alles drin :slight_smile: operator und website fehlen aber könnte ich verschmerzen :wink:

zum Copy&Paste wäre eine Zweispaltige Tabelle besser… eine für Master eine für Route besser… dann könnte man alle Key/Values auf einmal kopieren :slight_smile:

‘operator’ ist drin, wenn es in den GTFS-Daten als “agency” drin ist (AVV und andere haben das). Beim MVV ist es eigentlich immer MVV == ‘network’

‘website’ kann ich noch machen. Derzeit nur drin, wenn die Route (in GTFS) selber einen eigenen Wert hat (route_url) - ansonsten kann ich agency_url nehmen, die sollte auf den operator oder den Verbund verweisen.

Kein Problem, ich trickse das mal so, dass die beiden jeweils 2-spaltigen Tabellen nebeneinander stehen - ohne leere Zellen (wenn möglich).

ja genau das kann man machen :wink: eine Unsichbare “Design” Tabelle… in der zwei Tabellen sich wiederum befinden :slight_smile:

<table style="float:left; margin-right: 20px;">
...
</table>
<table>
...
</table>

macht’s.
Wobei aus irgendeinem Grund die rechte (untere) Tabelle länger sein sollte, sonst rutscht der nächste z.B.

auch noch nach rechts daneben.

Sehr schön :sunglasses: das ist natürlich moderner :slight_smile:

ach ja… Toni was bedeutet dieses “V” bzw. “W” hinter den Liniennummern (Bus) beim MVV? :confused: Ich denk mal du wirst es wissen :wink:

‘V’ scheint wohl Verstärkerbus zu bedeuten (meist nur zu Schul-begin und -ende)
‘W’ ist recht neu, kenne ich erst seit Dezember. Könnte aber das selbe bedeuten.

Die tauchen zum Teil nicht in den GTFS-Daten auf.
Wenn man aber beim “Fahrplanbuch” des MVV mal 211 eingibt, kommt auch 211V und 211W als Auswahl.
Oder nur ‘V’ oder nur ‘W’ eingeben, dann gibt’s 'ne Übersciht.