Bug in handling re-used shape_ids

[JesseWeinstein]

I've observed that, for GTFS data that has two different sets of stops that use the same shape_id, PTNA behaves incorrectly. Here's an example:

https://ptna.openstreetmap.de/gtfs/US/trips.php?feed=US-MA-MBTA&release_date=2023-09-01&route_id=CR-Fitchburg

Note that this shows 4 route variants.

However, there are actually two different sets of stops that use the same shape_id:

https://ptna.openstreetmap.de/gtfs/US/single-trip.php?feed=US-MA-MBTA&release_date=2023-09-01&trip_id=CR-595163-1404 https://ptna.openstreetmap.de/gtfs/US/single-trip.php?feed=US-MA-MBTA&release_date=2023-09-01&trip_id=CR-606471-420

And linking to the shape_id just picks one of them, arbitrarily:

https://ptna.openstreetmap.de/gtfs/US/single-trip.php?feed=US-MA-MBTA&release_date=2023-09-01&shape_id=9840003

It probably should show an error message, and link to the two different possibilities.

[osm-ToniE]

Thanks for reporting this.

In this particular case, the shape data of the second trip is wrong. https://ptna.openstreetmap.de/gtfs/US/single-trip.php?feed=US-MA-MBTA&release_date=2023-09-01&trip_id=CR-606471-420 if you have a look on the map west of stop #1. In this case, GTFS analysis could report that stop #1 is too far away from shape point #1 - or in general: a stop is quite far away from the closest shape point.

Anyway, the issue is valid as for, for example, an express bus skipping every second stop of a regular bus using the same route, having even different route_ids.

[JesseWeinstein]

Yeah, I agree that in this example, the GTFS data is wrong. But as you said, it does show an example of odd/wrong behavior by PTNA, with regards to distinguishing the different route variants.

[osm-ToniE]

After a deeper analysis, it splits into several different issues

• trips with same sequence of stop_ids get aggregated by PTNA to a single representative trip

  • including only the shape_id of the representative trip
  • the others may have different shape_ids though
  • those shape_ids may nevertheless show the same shape data (is this an error in GTFS, or at least redundant and bad design?)
  • those shape_ids get lost during aggregation - which is an error in the GTFS aggregation code
  • PTNA's GTFS analysis shall report a suspicious number of shape_ids in this case does not have to check whether their actual shapes are identical

• two different representative trips of the same route may show same shape_ids

  • this should be treated as an error in GTFS as discussed above: they have different stops, so they can't have same shapes

• two different representative trips of different routes may show same shape_ids

  • this should not be treated as an error in GTFS as discussed above for express vs regular bus - theory only, I have no example data

If a shape_id is used by more than one trip_id PTNA should be able to handle that:

• in the analysis code: shape_id is ambiguous, a trip cannot be identified by that
• on the web site: present a page where the trips (and their route_ids) are listed

[osm-ToniE]

PTNA will now link to the page 'shape.php?...&shape_id=...' (instead of 'single-trip.php?...&shape_id=...') and this new page will handle the stuff showing the shape only, printing the trip(s) (as URL) which follow this route.

There are no other checks. Maybe in the future, PTNA may raise an error/note when only "gtfs:shape_id" (and not gtfs:trip_id*) is set in a route relation and shape_id is ambiguous.