PTNA-Tool und GTFS-Daten in Österreich

Communities Österreich (Austria)
, ,
61

Nachdem ich hier ein besonderes Ungetüm einer unübersichtlichen Buslinie gefunden habe (Linie 1839 im VOR ist mir noch eine Idee gekommen, wie man mit dem GTFS Tool die Stammstrecke möglicherweise leichter auffindbar machen könnte.

Könnte man alle Routen auf einer Karte als Heatmap überlagert darstellen? Auch wenn eine Gewichtung nach Fahrtanzahl offenbar nicht so einfach möglich ist (das wäre natürlich am besten), wäre so ein Vergleich hilfreich. Durch (extrem) viele Routenvarianten zeigt sich auch hier eine gewisse “Stammstrecke”.

Ich denke, diese Abbildung wäre ein schöner Überblick über eine Linie.

62

Eine grobe Gewichtung nach Fahrtanzahl scheint mir als Algorithmus doch machbar zu sein, anders als ich in PTNA-Tool und GTFS-Daten in Österreich - #56 by ToniE angedeutet hatte.

Für eine Variante kenne ich derzeit die Abfahrzeiten (also auch deren Anzahl) und die ‘service_ids’ aus GTFS

  • calendar.txt:
"service_id","monday","tuesday","wednesday","thursday","friday","saturday","sunday","start_date","end_date"
1,1,1,1,1,1,0,0,20230202,20231209

d.h. grob die Anzahl der Tage zwischen 2023-02-02 und 2023-12-09 multipliziert mit Anzahl der Wochentage an denen gefahren wird (hier Mo-Fr) dividiert durch 7 (Tage pro Woche)

  • calendar_dates.txt
"service_id","date","exception_type"
1,20230410,2
1,20230501,2
1,20230529,2
1,20231003,2
1,20231031,2
1,20230518,2
1,20230407,2

Ergebnis von oben plus die Anzahl der “exception_type” == 1 (auch an diesem Tag) minus die Anzahl der “exception_type” == 2 (nicht an diesem Tag)

Das ganze multipliziert mit der Anzahl der Abfahrzeiten für diese “service_id”

All das über alle zur Variante gehörenden ‘service_ids’.

Das sollte sogar für diese Variante meines Busse 210 machbar sein - sogar dynamisch auf der Webseite.

Besser wäre es aber, diese Zahl bei der Vorbereitung/Aggregation der Daten zu berechnen (bevor sie auf den Webserver geladen werden), denn die Zahl verändert sich ja nicht.

Auf eine Heatmap mit einer Karte würde ich dann zunächst verzichten, ist deutlich aufwändiger.

PTNA: news for Public Transport Network Analysis
PTNA: news for Public Transport Network Analysis
63

Hab’s gerade freigegeben.

1 Like
64

Mit Anfang Mai gab es offenbar eine großflächige Umbenennung von gtfs:route_id. Jetzt steht ein Kürzel des Verkehrsverbunds drinnen, dafür keine Info mehr über das Jahr.

Beispiel:
Alt: 70-107-j24-1
Neu: at:vor:107:

Beim VOR und VVST wurde das soweit ich das sehe bei allen Linien gemacht. In anderen Bundesländern noch nicht. Weiß jemand, ob das überall kommt? Oder ob das überhaupt bleibt?

Aus OSM-Sicht ist es ärgerlich, dass hier ohne Änderung vor Ort die Verlinkung gebrochen wurde. Aber grundsätzlich ist glaube ich das neue Format, auch weil es ohne Jahreszahl ist, stabiler. Vielleicht erleichtert es den gerade entstehenden gtfs-Vergleich?

Die Änderungen seht ihr zB hier: https://ptna.openstreetmap.de/gtfs/compare-versions.php?feed=AT-VOR&release_date=2024-05-01&release_date2=2024-04-03

65

Eigentlich hat man drei der vier Elemente in der alten route_id ersatzlos gestrichen

  • “70” entspricht Fahrzeugtyp (bus, …)
  • “j24” das Jahr des Fahrplans
  • “1” eine Versionierung innerhalb des Jahres (wird von DE-BY-MVG und DE-BY-MVV oft genutzt)

und hat zwei redundante Elemente hinzu gefügt

  • "at’ das Land
  • “vor” den Verkehrsverbund

Zwei Elelemnte die durch das GTFS-Zip-File schon her bekant sind (feed-info.txt, agency.txt)

66

Hallo,

Danke für das tolle Tool! Ich habe in letzter Zeit einige Zeit damit verbracht GTFS und OSM Daten in Österreich zu vergleichen und seit ich über PTNA gestolpert bin, ist das deutlich leichter.

Eine kurze Frage: Gibt es einen Grund warum die U-Bahnen in Wien nicht in der Analyse aufscheinen?

PTNA - AT-VOR

Der Eintrag in der Tabelle sieht ja richtig aus:

U1;subway;;;;Wiener Linien;AT-VOR;at:vor:3301:

Update:

Okay, ich glaube es liegt daran, dass wie in Section 5 erwähnt, nur Routes mit network=VOR berücksichtigt werden, aber die U-bahnen network=U-Bahn Wien haben.

Damit zusammenhängend fällt mir auf, dass nicht regionale ÖBB Zugverbindungen (also die meisten routes aus AT-Eisenbahn) in keiner der Auswertungen auftaucht. Wäre es vielleicht möglich eine neue Kategorie in PTNA - Auswertungen für diese zu erstellen?

67

Genau. Das ist auch schon im NSI behoben. Ich persönlich wollte noch iD v2.38 abwarten, damit dieser falsche Vorschlag nicht sich teilweise wieder wo reinschleicht.
Mit der NSI-Aktualisierung wird dann auch wieder train=yes bei den U-Bahn-Stationen vorgeschlagen, aber da hab ich noch nicht herausgefunden wie man das ausschließen kann.

1 Like
68

Ich werde erst einmal nachschauen, warum die bei AT-Eisenbahn fehlen und dann dort ergänzen.
Dort sollten, mMn alle Züge auftauchen.

69

Ich könnte natürlich auch diesen Wert erlauben. Wenn ich Marvin richtig verstanden habe, braucht’s das aber nicht.

2 Likes
70

Nur um noch etwas klarer zu beschreiben, was ich meine:
AT-Eisenbahn schaut richtig aus (also die GTFS-Daten). Mein Punkt ist, dass ein großer Teil dieser Züge nicht wirklich mit einer der Verkehrsverbünde assoziiert sind (ich muss zugeben, ich bin mir nicht sicher, wie das mit Zugstrecken funktioniert, die über Bundesländer hinausgehen) und auf OSM meistens als network etwas wie ÖBB railjet haben (z.B. Relation: ‪Railjet Xpress Bregenz – Flughafen Wien‬ (‪20060930‬) | OpenStreetMap) was dann in keiner der Auswertungen von PTNA - Auswertungen auftaucht.

Wobei das bei genauerer Betrachtung doch weniger Züge sind, als gedacht und eigentlich glaube ich nur die Railjet, Euronight und ähnliche Verbindungen sind. Und öfter glaube ich einfach nur ein Paar Züge aus GTFS in den Wiki-Tabellen fehlen.

PTNA: news for Public Transport Network Analysis
71

Mein Fehler: Ich sollte wohl AT-Eisenbahn als PTNA Report anlegen, so wie DE-Bahnverkehr auf der DE-Seite. Dort werden alle [~'route'~'(train|light_rail|monorail)'] gesammelt.

3 Likes
72

Wo im OSM-Wiki soll ich die CSV-Daten ablegen/erwarten?

  • Austria/Eisenbahnverkehr/…
  • ???
73

Wenn wir schon mal beim Thema der Bahnrelationen sind:

Gibt es einen Grund, warum die tracks- und railway-route-Relationen zwar anscheinend im Quellcode ignoriert werden, aber trotzdem über ⅜ der Einträge in #morerelations der österreichischen Analysen ausmachen?

74

PTNA hat zwei Suchmethoden

  • Overpass-api:
    • hier werden alle gewünschten route=x Relationen gesucht und dann deren Eltern-, Großeltern-, … und die Geschwister d.h. Kinder der Eltern-, …
    • irgendwie kommen z.b. via type=network auch andere route=y rein.
    • aber Das soll als Hinweis gesehen werden, dass Relationen keine Kategorien/Sammelrelationen sein sollten
  • Planet-Exract und osmium filter, die nächtliche Analysen
    • hier bin ich mir noch nicht sicher, wie die reinkomen. Evtl. ein ähnlicher Mechanismus. Da kenne ich mich noch nicht so gut aus und habe mit den Filtern noch nicht rum experimentiert

Ziel ist es aber, dass im PTNA-Report kein (großer) Unterschied zwischen nächtlichem Report und on-demand Report zu sehen sein soll.

1 Like
75

Btw. Zu PTNA Report für AT-Eisenbahn komme ich morgen erst.

1 Like
76

Bin dran, sollte in 30 Minuten verfügbar sein, CSV als Template unter Austria/Eisenbahnverkehr/Analyse/Eisenbahn-Linien - OpenStreetMap Wiki

4 Likes
77

Vielen Dank!

Ich fürchte mir fällt damit auf, dass ich die ÖBB GTFS-Daten noch deutlich weniger verstehe, als ich gedacht habe. Bzw. verstehe ich, warum die Fernverkehr-Einträge in PTNA - DE-Bahnverkehr nicht mit GTFS verknüpft sind.

Warum ist zum Beispiel der Railjet von Wien nach Břeclav in derselben Route wie der vom Flughafen nach Innsbruck?

Um mal den ICE 90 als Beispiel zu nehmen: Laut trips.txt hat dieser 4 Trips auf den routes 14-D98-j26-1 und 14-A98-j26-1. Einer dieser tripts ist z.B. PTNA - GTFS Analysen. Immerhin hat die Route A98 nur (14-A98-j26-1) Verbindungen zwischen Wien und Passau. Aber ich bin mir nicht sicher, ob das bei allen A*-Routes so direkt mit “erkennbaren Namen” zusammenhängt.

Ich vermute, ich muss mir nochmal genauer anschauen, was transitous mit dem GTFS Archiv macht (transitous/feeds/at.json at b14ab0c06bd4ac67278fc56400912b314cc5904e · public-transport/transitous · GitHub), da die postprocessed https://api.transitous.org/gtfs/at_Railway-Current-Reference-Data-2026.gtfs.zip von Sources | Transitous anscheinend mit gtfsclean die Routes aufgesplittet hat. Und somit eine bestimmte Verbindung (Beispiel) einen schönen Namen anzeigt anstatt einen die Wahl zwischen A1 und AD3 zu geben.

78

Ah, okay:

gtfsclean 20260123-0052_gtfs_evu_2026.zip -o out.zip --fix --copy-trip-names-matching "((IC)|(ECB)|(EC)|(RJ)|(RJX)|(D)|(NJ)|(EN)|(CJX)|(ICE)|(IR)|(REX)|(R)|(ER)|(ATB)|(WB)) \\d+" --keep-route-names-matching "((RE)|(RB)|S) ?\\d+"
schreibt tatsächlich die routes so um, dass jeder Trip eine eigene route wird und die trip_short_name (wie “RJX 251”) zur route_short_name wird.

Das löst mein Problem (dass der bekannte Name im Routing verwendet wird), aber ich fürchte, das hilft für OSM routes nicht wirklich.

79

Hab ich jetzt korrigiert und gleich zusätzlich network:metro=U-Bahn Wien gesetzt.