PTNA: news for Public Transport Network Analysis

I just added the last of another 14 analysis of #public_transport for

  • India

to ptna @ the sub-page for India

The empty entries will be filled during the next run @ 23:30 UTC

I just started a new thread about comparing two GTFS feed versions using PTNA


I added analysis of #public_transport for

to ptna based on GitHub issue #93

gtfs support will follow later

I added gtfs analysis of #public_transport for

to ptna based on GitHub issue #24

1 Like

I fixed a bug in GTFS analysis reported by @JesseFTW based on observations for US-MA-MBTA concerning shape_ids.

Shapes describe the route a vehicle uses to get from stop to stop.
Attention is required for example for the following situations where a shape_id may be

  1. used by different trips of the same route with same stops - like two trips of the " Franklin/Foxboro Line" - just toggle between the following links
  1. used by different trips of different routes (examples:)
  • a regular bus which stops at every stop on the route
  • an express bus using the same route but skipping for instance every second stop

PTNA’s GTFS analysis did not handle the issue #1 correctly and aggregated both to a single trip, omitting one of the two shape_ids. This has been fixed - a trip is identified by the stops (stop_id) it touches plus the route (shape_id) it takes.

The fix will be available for all GTFS feeds downloaded and analysed started October 1st, 2023 and later.

See the details in GitHub for PTNA’s

BTW: PTNA’s GTFS analysis does not check whether two different shape_ids describe exactly the same route - I’ve seen some of them. I see this as a task for a GTFS validator, not for PTNA. And: is this actually a bug or “room for improvement”?

1 Like

I just added gtfs analysis for the Netherlands

  • NL-Nationaal - covering the whole Netherland

to ptna based on discussion in “GTFS in Nederland

1 Like

Hi, für DE-BE-VBB gibt’s Fehlermeldungen der Art Fehlende Linie für ‘ref’ = ‘RB23’ und ‘route’ = ‘train’, aber die Relationen sind doch da?, Was verstehe ich falsch?

Zunächst einmal die gute Nachricht: Die OSM-Daten sind korrekt!

Die GTFS-Daten des VBB listet die RB23 zweifach auf, warum weiss ich nicht, denn eine davon ist nicht im VBB-Gebiet sondern bei Insel Usedom (Beispiel).

Für die PTNA-Analyse habe ich seinerzeit (04.04.2020) die Liste der VBB-Linien aus den GTFS-Daten erstellt.
In dieser Liste ist die RB23 (mit Operator = DB Regio AG) nun doppelt enthalten und PTNA weiß nicht welchem Eintrag die RB23 im VBB-Gebiet zuzuordnen ist. Daher listet PTNA diese RB23 (und andere) unter dem Kapitel “Nicht eindeutig zugeordnete Linien” auf.

Wie kann ich’s beheben?

Für die RB23 kann der erste Eintrag (“RB23;train;19686_100;;;DB Regio AG”) in der Liste wohl entfernt werden, da diese nicht im VBB-Gebiet liegt.

Für andere nicht eindeutig zugeordnete Linien müssen ‘operator’ in der Relation und in der Liste übereinstimmen, damit PTNA eine Zuordnung machen kann. Sollte das nicht reichen, dann müssen noch ‘from’ und ‘to’ entspr. gesetzt werden (bitte in dem Fall nochmals rückfragen).

Die Liste im OSM-Wiki wurde bisher fast nur von mir bearbeitet - das ist aber nicht Sinn der Liste. Die Liste ‘gehört’ lokalen Mappern und sollte/kann von diesen jederzeit aktualisiert, korrigiert, neu-sortiert, anders strukturiert werden.

HTH Toni

I just added analysis of #public_transport for

to ptna

1 Like

I just added analysis of public-transport for

to ptna

1 Like

I just added analysis of public-transport for

to ptna

gtfs data has been added now

1 Like

I have a feature request for the gtfs analysis.

If the stop name of the first or last stop contains common abbreviations, automatically change them to the long name in the tagging proposal for to, from and name.


name should be Sankt Bartolomä Ort instead of St.Bartholomä Ort

That has been implemented in the “normalization” step.

“St.” is a tricky part. Sometimes “St.” is the more correct form, so I skipped that.
But this special case (and others) can easily be added.

To avoid wrong expansions, the list of generic changes is rather short and the focus is on known cases
Generic cases:

  • Str\. -> Straße
  • Str$ -> Straße
  • str$ -> straße
  • str\. -> straße


  • R\.-Diesel -> Rudolf-Diesel
  • Ludw\.-Ganghofer -> Ludwig-Ganghofer

Wobei man bei language=de_CH “Strasse” nehmen müsste - was nicht der Fall ist.

Maybe such “tricky cases” could be highlighted to raise the attention for manual checks?

For example:
St.Bartolomä Ort
Sankt Bartolomä Ort

And colour those table cells red.

Currently the

  1. “normalization” happens only once, only when the GTFS data is read from the internet and prepared. After that the data is copied to the Web-server area.
  2. The Web-code (PHP) does not perform any further analysis (on-the fly), just to unload the Web-server from repetitive tasks which (could) have been done in step #1

So, recognizing that “St.Bartolomä” is a candidate for expansion is task @ #1, but not done.
Marking tricky cases (colour, strike-out) is task @ #2, but there is no code for that and I want to avoid having analysis code here.

But: I can add “St.Bartolomä Ort” → “Sankt Bartolomä Ort” to the “normalization” step.

What I could add in general to task #2: mark all occurrences of all normalized names in light-yellow or so.
The Web-code knows whether there is the ‘name’ (stop_name, …) only or in addition also a ‘normalized name’

1 Like

In Austria, the most manual corrections I perform are:

  • St. → Sankt
  • Gh → Gasthaus
  • Abzw → Abzweigung
  • Bahnhst → Bahnhaltestelle
  • b. → bei

And those, which I believe can only be done manually

  • / → am, an der, in der etc
  • Deletion of Platform Refs (Graz Hauptbahnhof G → Graz Haupbahnhof)

Yep, I’ll add the first 5 transitions.

I also change the layout of the Web-pages, adding a column, displaying the ‘name’ and ‘normalized name’. This will make the changes more transparent to the readers.