PTNA - News: GTFS-Analyse

Communities Deutschland (Germany)
48

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:

49

… 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.

50

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).

51

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:

52

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.

53

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

54

Hi Miche,

ist fertig, auch für Route-Master.

Welche Tags würden dMn noch fehlen?

Gruß
Toni

55

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:

56

‘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).

57

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

58 
<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.

59

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

60

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

61

‘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.

62

OK, Verstärker… Dann kann es zur Linie gleich, aber auch ganz anders sein :expressionless:

Glaub da ist nix… Definiert :confused: das kann jeder anders machen… muss halt für das jeweilige gtfs Datei eindeutig sein. Kann sich also ändern, je nachdem wie die Software des Herausgebers arbeitet :confused:

63

Stimmt, das macht quasi jeder anders. Ich sehe aber auch Ähnlichkeiten, die auf die dahinter liegenden SW (Mentz?) schließen lässt (Ähnlichkeiten zum MVV, der mit Mentz zusammen arbeitet).

Was ich meinte war: für den MVV z.B. ob sich die route_id und trip_id innerhalb des Fahrplanjahres bei Updates der GTFS-Daten ändern? Einfach nur so, weil’s ein Update ist. Ausgenommen Änderungen, wenn sich am Bus was ändert.

Was ich beim MVV bemerkt hatte: route_id und trip_id enthalten so was wie “s20” oder “s19”, was auf das Jahr zurück schließen lässt.

Edit: wie heißt es so schön: “Hoffe das Beste, rechne mit dem Schlimmsten!”.

64

ja g

Wie gehst du jetzt vor mit updaten der Relationen… anhand z.B. Bus 463. Ich zähle da jetzt 14 Varianten (1) auf der Analyse Seite sind gerade 17 Varianten gemappt (2). Also 3 zu viel… und eine Haltestelle muss dazu (Pliening, Kirche). Der Fahrplan vom MVV hab ich auch (3). Aber jetzt ist es für mich sehr schwierig :confused:

Was mir einfällt ist im GTFS gibt es auch die Timetable… das würde mir helfen den Trip zum Fahrplan zuzuorten… wenn ich die Abfahrzeiten hätte. Bleibt aber wie ordne ich die Relationen am besten zu… um dann die nicht mehr vorhandenen Relationen zu finden :confused:

1 - https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-BY-MVV&route_id=19-463-s20-1
2 - https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#A2.5.6.3
3 - https://efa.mvv-muenchen.de/ttb/mvv_19463___H_s20_2.pdf

65

Hier wäre mein Ansatz zunächst: Start- und End-Haltestelle vergleichen und herausfinden, welche Variante es ist.

Diese PDFs habe ich in der Vergangenheit auch immer benutzt - für unsere Zwecke grauenhaft, nervig. Davon will ich weg.

Yep, das bereitet mir noch Kopfzerbrechen.

Durch die Zusammenfassung identischer Trips mit unterschiedlichen Abfahrtzeiten auf einen einzelnen Trip gehen diese Informationen verloren - bis auf die Abfahrtzeit des repräsentativen Trips. Die könnte ich zumindest ausgeben, dann hätte man einen (von vielen) Link ins PDF.

Was mich noch hindert, alle Abfahrtzeiten zu nutzen (aufzusammeln) ist die Menge, die sich z.B. beim 210er ergeben wird. Der fährt nahezu alle 10 Minuten in jede Richtung + Verstärkerbus … 6 * 20 Stunden * 2 Richtungen + Verstärker ~ 250 Einträge ?

66

Schau mal, ob das weiter hilft.

67

ja das ist schon mal gut :slight_smile: :slight_smile:

Ja stimmt das ist schon schon ein wenig viel :confused: Aber das könnte man auch nach so und soviel Zeichen mit “…” abschneiden und in Klammer (“Gesamtzahl”).

Ja Gesamtanzahl? Also wie oft dieser Trip gefahren wird? z.B. ( https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=6.T0.19-463-s20-1.9.H ) finde ich jetzt schnell… wenn ich jetzt wüsste das dieser nur einmal gefahren wird… dann spar ich mir den vergleich auch :wink: