Correctly representing underground stops with multiple surface exits - does it require pathways?

[BodoMinea]

Hello everyone,

I am currently administering a GTFS feed for a metro (subway) Agency. The underground stations have multiple exits to the surface. To my knowledge, it is possible to instruct GTFS consuming applications to specify the most appropriate exit for their route. I have implemented as follows:

All stations are „described” by multiple stop_ids, with the following parameters:

Example Stop - general stop with location_type=1, we'll refer to it as „Main ID”
Example Stop Platform 1, location_type=0, platform_code=1, parent_station=Main ID
Example Stop Platform 2, location_type=0, platform_code=2, parent_station=Main ID
Example Stop Exit A, location_type=2, parent_station=Main ID
Example Stop Exit B, location_type=2, parent_station=Main ID
Example Stop Exit C, location_type=2, parent_station=Main ID

Trip stop_times indicate them as stopping in Example Stop Platform 1 and Example Stop Platform 2 respectively.

Upon testing the feed as constructed above with consuming apps, it doesn't fully do what I intended.

With „Example Stop” being tested as a trip starting and finishing point, the platforms work correctly but the exits not quite. Planning results are of the form „Enter Example Stop at Example Stop Exit A (entering and exiting stations is always suggested through exit A, even if exit A is farther away from the starting / finishing point, even though exit B would have been much closer), board vehicle from platform 1/2 (correct)”.

So it seems like only one stop exit is always used, regardless of what would be more appropriate for the user's itinerary. Now the exits are only linked to the stops referenced in stop_times by having the same parent_station.

Do you have any thoughts on what should I do to solve this issue? Do I need to generate the pathways.txt file and link the exits to their corresponding stops...? And if that's the case, what should they link to? Towards each platform (all exits can be accessed from both platforms) or to the main station ID (which has no stops)? From the reference available at https://developers.google.com/transit/gtfs/reference#stopstxt it looks like I can only specify station platform and exit hierarchy and it should work without pathways. Answers on the MobilityData Slack seem to point to this opinion too.

Could anyone give insight on how to properly implement this or point to a feed example which would clarify my unknown details? Thanks!

[skinkie]

I wonder if this is more an issue with the consuming GTFS application, than your examples. @t2gran @abyrd is this something that is correctly solved in OTP2?

[skinkie]

@BodoMinea I think that pathways would make this less ambiguous, but I would expect that if you would not the relationship should be inferred by an as the crow fly distance.

[BodoMinea]

The problem with pathways is that once supplied for a station they should be exhaustive. Since I only get data about the station's "imaginary center point" and surface access ways, I cannot accurately represent all possible footpaths inside the station (between platforms, etc.) - at least not yet. Therefore, I would like to represent the entrance points as being at an as the crow flies distance from the actual boarding points but to have them indicated/used correctly when the user has one of these stops in his itinerary. However, OTP (at least the hsl/digitransit fork I have at my disposal) and Google Transit don't seem to cooperate with this arrangement. So at a conceptual level the GTFS looks ok in your opinion?

[skinkie]

The problem with pathways is that once supplied for a station they should be exhaustive. Since I only get data about the station's "imaginary center point" and surface access ways, I cannot accurately represent all possible footpaths inside the station (between platforms, etc.) - at least not yet. Therefore, I would like to represent the entrance points as being at an as the crow flies distance from the actual boarding points but to have them indicated/used correctly when the user has one of these stops in his itinerary. However, OTP (at least the hsl/digitransit fork I have at my disposal) and Google Transit don't seem to cooperate with this arrangement. So at a conceptual level the GTFS looks ok in your opinion?

Lets say if I would receive a feed with entrances, then the entrances would link to the street network (exhaustively instead of the stops), and then the entrances would do a connection to all the stops in side the station within the data model of the journey planner.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to inactivity. Issues can always be reopened after they have been closed.