PTNA: news for Public Transport Network Analysis

Hey Toni,
Might be a rare case, but since the wiki is kind of down at the moment it might be a good idea in the future to keep the last version of the routes.txt on your server and just update them before your an analysis is triggered. In case the wiki is not reachable, keep your version and use it for the analysis.

1 Like

Yeah, I had the same idea this afternoon after seeing that 3 read requests had a timeout in the early morning.

1 Like

This is a thread about PTNA.

Maybe it is better to open a new thread about PTSA or contiune here: New tool for analysing OSM public transport stop data

There is no connection between PTNA and PTSA, neither persons nor code nor anything esle.

1 Like

Sorry for brother you, thank you. www

I noticed that there is no avaliable result in my intreseting regions, such as Shanghai, Tokyo and Taipei. Can I make a request for these area?

Sure, just give me some details like

Are there also any GTFS data available with compatible licence, compatible to OSM?

Maybe you can try this?
Area: Shanghai, China, city relation 913067
Network: Shanghai bus and Shanghai Metro
Links: 上海市交通委 with public app “随申行” issued by SMTC and 上海地铁
Wikipages: Zh-hans:上海公交 - OpenStreetMap Wiki plus Zh-hans:上海公交 1 - OpenStreetMap Wiki and Shanghai Metro - OpenStreetMap Wiki
There is no any GTFS data are applied in China mainland.
Maybe we can consider the bus, ferry and subway in a whole system?

I just released two new functions

  • GTFS’ ‘platform_code’ is mapped to OSM’s ‘local_ref’ on stops/platforms

    • the ‘platform_code’ will be shown on the page where details for trips are shown: stop-list. Of course, values depend on GTFS feed data.
  • If reading CSV-Routes data from the OSM wiki fails, old data (from the day before) will be used avoiding huge ‘diff’ reports (thanks @aighes for the suggestion)

Thanks, I’ll try that tomorrow.

Sure, PTNA can fetch all PT relations from that region and analyse them in one go.

Is it OK then to name the analysis CN-SH-SMTC ? Or do you have an alternative for “SMTC”

1 Like

Maybe I think just name CN-SH-Shanghai is better. SMTC just an abbreviations for government transportation authorities.

1 Like

I just added analysis support of public-transport to ptna for

based on a request by @Herman_Lee

1 Like

I’m a little bit confused, I can’t find a logic for the identification of twin routes.
E.g. Havelbus

  • following routes will shown under “x_700”, but “x_3” keeps empty (correctly)

    • 604
      route_master + 1 route with gtfs:route_id=x_700
      6x route without gtfs:route_id
    • 651
      route_master with gtfs:route_id=x_700
      2x route with gtfs:route_id=x_700
      4x route without gtfs:route_id
    • 671
      route_master + routes with gtfs:route_id=x_700
  • route 652 - shown under “x_700” and “x_3”
    route_master with gtfs:route_id=x_700
    5x route without gtfs:route_id

  • following routes are not detected by PTNA

    • 688 - x_3 already disabling needed, although similar mapping like 652
      route_master with gtfs:route_id=x_700
      route without gtfs:route_id
    • 654 - x_3 already disabling needed, although similar mapping like 671
      route_master + routes with gtfs:route_id=x_700
    • 657
      route_master mit gtfs:route_id=x_3;x_700
      1x route mit gtfs:route_id=x_700 + gtfs:route_id_3=x_3
      1x route mit gtfs:route_id=x_3
      5x route mit gtfs:route_id=x_700

First of all: gtfs:route_id in the relation and route_id in the CSV are not considered at all for this

If there are two or more entries in the CSV with the same ‘ref’ and ‘type’, then it depends on ‘operator’ and if there is still more than one match it furthermore depends on the ‘to’ and ‘from’ values on both CSV and relation data.

We now have three options

  • filter out, what’s not relevant: route_id!=???_3
  • merge both CSV entries into a single one - not implemented by Inject-Code
  • create a single CSV entry manually, filtering out the automated one

==== Havelbus Verkehrsgesellschaft mbH

===== Eindeutig identifizierbar
- route_id 1924_3 von Bus 654 wird hier rausgefiltert: könnte ein Duplikat von Bus 654 route_id 1924_700 sein
-
- route_id 10685_3 von Bus 688 wird hier rausgefiltert: könnte ein Duplikat von Bus 688 route_id 10685_700 sein

- Bus 657 wird hier ausgeklammert und weiter unten explizit gelistet

@type=bus
@operator~Havelbus
@route_id!=1924_3
@route_id!=10685_3
@ref!=657
@@

===== Mix aus zwei GTFS entries
657;bus;;;;Havelbus Verkehrsgesellschaft mbH;DE-BE-VBB;"???_700;???_3"

Yesterday, I added analysis support for public-transport data of OSM to ptna for

I also removed the analysis support for

  • DE-BY-RoVG
    • the city and county of Rosenheim joined the DE-BY-MVV on 2025-01-01

Kindly be reminded that displaying the search area like Region München using Overpass-Turbo does not work at the moment due to bug #760 "Export -> Map -> as interactive Map" does not load data · Issue #760 · tyrasd/overpass-turbo · GitHub

I just removed analysis support of public-transport data of OSM in ptna for

I also renamed

Will you continue investigation? :smiling_face:

if possible, in my mind the best option

started already

will try this, together with 1. filtering out option (both temporarily?!) ok

Is it possible to add the manuell entries at the end of the same table without a separate title, like:

- Bus 657 erscheint am Ende der Liste aus Gründen

@type=bus
@operator~Havelbus
@route_id!=1924_3
@route_id!=10685_3
@ref!=657
@@
657;bus;;;;Havelbus Verkehrsgesellschaft mbH;DE-BE-VBB;"???_700;???_3"
-

or is it faulty?

P.S.
I have identified twin routes only by 4 operators: Havelbus, Oberhavel, prignitzbus and regiobus Potsdam Mittelmark,
further investigations not done

It’s fine :slight_smile:

I need to work on this - I have quite a bit of real-world distractions but I think I’ll get around to it soon.

Yes, I had an idea, but that seems to be no longer valid, have to investigate further, seem sto be quite complicated.

I’m also thinking about using ‘operator’ and ‘to’, ‘from’ only after having checked CSV:route_id against OSM:gtfs:route_id to distinguish ???_700 and ???_3 - this way allowing two CSV entries but then also having two route_masters.

Is it worth investigating further assuming ???_3 and ???_700 are bugs in GTFS?