PTNA: news for Public Transport Network Analysis

General talk
, ,
663

Based on Github issue Add US-OK-MTTA · Issue #65 · osm-ToniE/gtfs-feeds · GitHub by @Baloo_Uriza, I just added analysis support for public-transport data of osm to ptna for

664

PTNA is currently undergoing major renovations. See the announcement in the community forum.

this is still on https://ptna.openstreetmap.de/ and links to 2024 post. If that outdated by any chance?

665

Thanks for asking!

Yes and no! It took me nearly 2 years to finalize that and I’m now fine-tuning the last bits.
Last activities are about finding appropriate ‘osmium tags-filter’ settings so, that the reports generated from Overpass-API data versus generated from planet extract data are nearly identical.

I hope to finish this task this week.

4 Likes
666

I’ve discovered this week that Metropolitan Tulsa Transit Authority actually kept that name, but provides service as MetroLink Tulsa. So based on this new information, I’m thinking network=MetroLink Tulsa and operator=Metropolitan Tulsa Transit Authority might be the winning combination? Open to feedback.

667

After nearly 2 years of work (with interrupts of course), I just released the final bits and bolts for PTNA’s switch-over from Overpass-API to Planet extract data.

Final bits and bolts: adjusting filter rules. You’ll notice that with the next report (tomorrow), starting with UTC+10 (Australia, where “tomorrow” already started).

As mentioned, the queries towards Overpass-API and ‘osmium tags-filter’ are different.
I tried to reduce the differences as much as possible.

PTNA is nearly 100% Overpass-free:

  • nightly reports are 100% Overpass-free
    • only the fall-back is Overpass-API
  • on-demand report generation is still based on Overpass-API data
    • data is nearly up-to-date and not more than 1 hour old
    • this is around max 10 requests per day, in total less than 1GB
    • requests are sent by PTNA
  • on-demand comparison of GTFS versus OSM data is based on Overpass-API data
    • these are less than 5k requests per day with small amount of data each
    • requests are sent by the user’s browser (JavaScript)
13 Likes
668

Based on a suggestion by @donmac703, I just released a new small feature for ptna.
The new feature will be active next night (local time of report), starting with UTC+10 (Australia) in about 5 hours.

I’d like some feedback regarding the tag bus=yes often seen on (PTv2) bus platforms (optional) and (PTv2) bus stop_positions (mandatory) - ‘bus’ as an example here.

In general, bus=*, access=*, vehicle=*, foot=*, … are access right specific keys.

PTv2 handles this bus=yes (and tram=yes, train=yes, …) as an indicator for the type of vehicle using this platform/stop_position. This has been criticised in the past.

N.B. the code finds some typos: ‘bus=^y’, ‘bus=yeslit=yes’, … but also ‘access=private’ which seems not to fit to public transport.

Any thoughts, comments regarding this new check?

669

I like the new check as i was able to find this ‘bus=yeslit=yes‘ error i made in the past.

For the access as indicator keys:
As long PTv2 has no indicator on its own, the access keys bus=*, tram=*, train=*, etc… are the best options we have to dedifferentiate between the different forms of transportation as of right now.
A subkey like ’public_transport:type=*’ could work for this, however we also need to in mind the access keys are in use for this for a long time by now. It is still worth wile to talk and discus over this potential addition to the PTv2 scheme.

1 Like
670

I’m OK with that, just wanted to mention this and the discussions about that.

671

Yeah i apologies for my wording. I was thinking about leaving this part out, but didn’t in the end.

672

No need for apologies. I agree with that wording.

673

Based on request by @Baloo_Uriza, I just completed the support in ptna for gtfs data analysis for

See also: PTNA: news for Public Transport Network Analysis - #663 by ToniE
See also: Add US-OK-MTTA · Issue #65 · osm-ToniE/gtfs-feeds · GitHub

1 Like
674

Based on a suggestion by @donmac703, I released a new feature to ptna 10 days ago

Analysis option (set by me on request)

  • --exclude-if-key-value

How it works

  • exclude route_master and route relations from analysis if the key=value is found on the relation

Use cases

  • filter ‘foreign’ relations, relations from networks outside the search area
    • those relations may have the same ‘ref’ as the relations of interest
      • those cases might cause an error report of
        • two route_masters and their routes for the same entry
        • both route_masters and their routes in the section “Not clearly assigned routes”
      • this makes maintenance of CSV data complicated
        • ‘operator’ values must be set for the relations and CSV data and the values must match

Example

  • analysis of AU-NSW-All allows all ‘network’ values for the analysis
  • this includes also ‘network’ values of routes in AU-QLD
  • this potentially includes same ‘ref’ of routes from AU-NSW and AU-QLD
  • set: --exclude-if-key_value='gtfs:feed=AU-QLD-South-East-Queensland'

Report

  • the excluded relations will be reported in a separate section but no analysis will be done

Please contact me if you think this could be useful for you analysis

Edit: add links
Edit: ‘my’ → ‘me’
Edit: ‘be’ → ‘by’

1 Like
675

For ptna’s analysis reports, I just released support for gtfs tags (OSM keys) with the feed-name as suffix of the key:

  • gtfs:release_date:<feedname>
  • gtfs:route_id:<feedname>
  • gtfs:trip_id:<feedname>
  • gtfs:trip_id:sample:<feedname>
  • gtfs:shape_id:<feedname>
  • gtfs:stop_id:<feedname> is already supported in the GTFS vs OSM comparison

This support closes a gap in PTNA regarding the GTFS description in the OSM wiki, namely the sections:

Current support allowed only the gtfs:feed key to specify the name of the feed

N.B.: PTNA now supports both, however choose one or the other, do not mix both variants for the same relation:

  • Example for bus 210 of the “Münchner Verkehrs- und Tarifverbund” (DE-BY-MVV)

    • gtfs:release_date:DE-BY-MVV=2026-07-03
    • gtfs:route_id:DE-BY-MVV=19-210
    • gtfs:trip_id:sample:DE-BY-MVV=19-210-trip12

  • Deprecated example for the same bus

    • gtfs:feed=DE-BY-MVV
    • gtfs:release_date=2026-07-03
    • gtfs:route_id=19-210
    • gtfs:trip_id:sample=19-210-trip12

In PTNA, there are still 3 gaps regarding this <feedname> handling

  • comparison of route_master and its route relations needs some improvement
  • the GTFS analysis still suggest tagging the deprecated version
  • the GTFS vs OSM comparison uses the deprecated version for the injection of data into OSM relation
676

Based on a PM by @mga_geo I released (some days ago) analysis support of public-transport data of osm for ptna for

677

I just released new formal GTFS checks for the first bullet point.

678

I know in Finland a few public bus routes go via stops which are in military zone or industrial areas which have restricted access by law. Quite unusual and rare thing.

In the UK there is at least Lympstone Commando rail station which serves a military facility. I don’t know if the general public have access to that platform.

679

According to the law, yes (it’s a public station owned by Network Rail on a public footpath).
According to the Ministry of Defence, yes but please don’t (they can’t really stop you though).
According to common sense, it’s in the middle of nowhere and looks like this so why would you want to go there (no-one really does other than soldiers)

image
image1920×1440 684 KB

1 Like
680

Yeah, I didn’t think of that use case. I guess, I’ll keep the code as is and wait for someone complaining about a false positive error message from PTNA.

681

Same in France, where it’s a normal bus route
Relation: ‪Bibus 27 : Roberval => Quatre Pompes‬ (‪13400213‬) | OpenStreetMap until the gate tagged psv=private

682

There are no complains from PTNA for this bus 27 PTNA - FR-BRE-Bibus even though there is this node with barrier=lift_gate and psv=private. The tagging at the highway=service behind the gate has access=no and psv=yes though, which is also OK for PTNA.