Pathways and levels

[LeoFrachet]

Hi GTFS community!

As explained last October in the issue #108, and as discussed in the Google Docs linked in the issue (bit.ly/gtfs-pathways), we've been working on extending GTFS to describe subway stations. Since the conversations faded out and since the consensus was reached, some agencies started to gather the data this Winter, including SF MTA, NYMTA & MBTA. They haven't put (as of today) those new fields in their production dataset, but we should be close to that for some of them.

From the full proposal, we extracted the mostly used fields, that you can either see in a Google Doc (bit.ly/gtfs-pathways-core) or in this proposal.

A first dataset has been created for King's Cross. It's publicly available for those who want to see what it looks like, or who want to start implementing: http://bit.ly/gtfs-pathways-tfl-kings-cross (the PR and the Google Doc are slightly different, since I updated the phrasing of the definition form the old version "The blabla field defines a something that" into the new phrasing: "Something that")

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

Googlers can find more info about SignCLA and this PR by following this link.

[gcamp]

I'm assuming stop_ids in stop_times.txt now can either be a Stop, Platform (type=0) or Boarding Area (type=4), but not Station (type=1), entrance (type=2) or generic nodes (type=3). Should that specified somewhere?

[LeoFrachet]

Good point. I’ll add it.

[skinkie]

If boarding areas are would be routable, this proposal becomes even a bigger mess. The authors were against a much more simple extension to allow an entrance to a platform. If the proposal is extending GTFS with a transit routable boarding area but not directly make stations transit routable as well, it seems clear that the only intention is to make GTFS more complex, and not better usable.

[LeoFrachet]

Guillaume (@gcamp): On second thought, no, I don't see what you're speaking about. StopTimes can only refer to stops (location_type=0). I agree that the definition in stop_times.txt should be updated from:

Referenced locations must be stops, not stations or station entrances.

To:

Referenced locations must be stops (location_type=0).

Boarding areas in this proposal are only used to route rider within stations.

[LeoFrachet]

Another dataset is publicly available. It contains the data for station Taverners Hill in Sydney (AU-NSW): http://bit.ly/gtfs-pathways-tfnsw-taverners-hill.

Both datasets (King's Cross and Taverners Hill) are currently used in the production version of Google Maps. Both to process walking time in station and to display "follow sign" information (from signposted_as field):

[LeoFrachet]

So we have data producers, which have made extract of their data public (for TfL & TfNSW stations) and we have a data consumer, Google Maps, using this data in production. Also the PR has been open for more than one week.

Therefore I opening the vote on the PR. The vote will be open until Tuesday 12 March at 23:59:59 UTC.

[skinkie]

@LeoFrachet is this a bogus claim? Previously it has been stated that Google was only using some parts of the pathway proposal, that previously existed and didn't have anything to do with your additions to it.

-1

[LeoFrachet]

I'll let Google answer directly.

[aababilov]

Hello from Google,
We fully support Core GTFS-Pathways since 21 Feb 2019. This is demonstrated by screenshots posted by Léo.

I am voting in favor of its addition to the core specification.

+1

[gcamp]

Can we have more details on what Google support and what is the "Core GTFS-Pathways" @aababilov ?

Also @LeoFrachet can you fix the conflicts before calling for a vote since there are going to be changes needed to be done anyway?

[LeoFrachet]

The "Core GTFS-Pathways" is what is in this proposal. Which is what Google support. It is a subset of the full GTFS-Pathways which is in the document bit.ly/gtfs-pathways.

And yes I'll fix the conflicts.

[dbabramov]

More details on Google's support for the proposed specification:

1. All new fields have been added to Google's validation pipelines, new warnings and errors (such as invalid values, unreachable entities, trips serving entities non-stops) have been added.

2. pathways.txt
   Google used to support single-step entrance-to-platform pathways in the past.
   Support has been added for multi-step pathway routing between station entities (pairs of platforms or entrances-to-platforms) via generic nodes.
   New fields:

• is_bidirectional: support for bi-directional pathways has been added;
• pathway_mode: not exposed directly in the UI; used in the evaluations of walking times between station entities and penalisation of walking routes that lead through multiple paygates;
• traversal_time: used in calculation of walking times;
• stair_count: does not show up directly in the UI, used in calculation of walking times;
• signposted_as, reverse_signposted_as: shown in the UI
• min_width and max_slope: not used at the moment, reserved for future accessibility support

3. stops.txt:

• Location types 3 (generic node) and 4 (boarding area) are used in multi-step routing between station entities (entrance-to-platform and platform-to-platform), and in calculation of walking times.

4. levels.txt:

• level_id, level_index, level_name - will not appear with routing results immediately. Used to link station entities to indoor modelling of stations where available.

PS:
+1

[abyrd]

I am now trying to consolidate information from throughout this thread so I can formulate an opinion on it.

@gcamp my understanding is that "core pathways" means the set of features listed in the document http://bit.ly/gtfs-pathways-core, and the changes in this PR are intended to represent exactly that set of features, which are a subset of the larger recent pathways proposal. However "core pathways" is a superset of the older pathways proposal from years in the past.

@aababilov and @dbabramov have confirmed that Google has implemented the entire set of features listed in the above-linked document, and would display or otherwise use all new data described in this pull request.

One source of concern is that this micro-mapping is relatively complex and would probably require special tooling to be widely adopted. Some less complex changes focusing on implicit connectivity among grouped entities (rather than explicit pathway topology) could promote better representation of compound stations across a larger number of data sets. But perhaps that should be a separate proposal.

There are also some decisions mixed into this PR (and the above comments) that might be considered orthogonal to the core issue of describing station pathway topology, specifically the idea that stop_times can only reference stops, meaning trips can only stop at specific platforms, rather than stations (when the platform is dynamically allocated and not yet known).

[LeoFrachet]

About the question of assigning station to stop_times (for when the platform isn't known yet), I agree it is orthogonal to the current conversation, and I'd rather have this conversation another thread. It's a really important conversation, and I've been gathering feedback on it, but it's distinct to the Pathways proposal.

[abyrd]

@LeoFrachet shall I create an issue for stop_times visiting stations, or were you already planning to create one including the information you've gathered?

On the topic of this PR, I am wondering about the inclusion of the additional levels.txt table in the minimal "core" proposal. I see that the levels section is a subset of the original at
https://docs.google.com/document/d/1qJOTe4m_a4dcJnvXYt4smYj4QQ1ejZ8CvLBYzDM5IyM/edit#bookmark=kix.tn25emxn4pie. But in reading that document and the core pathways doc at https://docs.google.com/document/d/1gQZBHrgBYnfSBDTeIeE3a8YMs7RKYaFjdNQm1Lz7sPU/edit I still don't fully understand the purpose. They say a levels table is required to tell people to get off at named floors, but a separate levels table is only one way to provide that information. The idea of defining feed-wide building levels that can be reused in different stations seems more strictly normalized than other parts of GTFS. It's also debatable whether a mezzanine level +1 in station A is really the same entity as a mezzanine level +1 in station B, as they are not the same physical floor (and not mutually connected to one another). I also don't see how such unification of levels would improve trip planning.

Might it be just as effective, yet less complex (avoiding a join), to include the level_index and level_name fields in the stops themselves? By way of comparison, we don't have a headsigns.txt table where many trips can reference the same headsign string.

[LeoFrachet]

Regarding scheduling on station, I opened an issue: #147

Regarding levels.txt vs just adding fields in stops.txt, I have no strong opinion (in fact I don't even have an opinion at all). I do not see one as being better than the other one. This is a part of the spec that I just kept from the original proposal.

But my concern is that now, in March 2019, we already have quite a few implementations done(MBTA, NY MTA, SF MTA, Google, London and some others stakeholders working on it). I don't know if all of them are supporting levels.txt (some might have no elevator, even if I doubt it). But it might be a bit late to change it if the two options are more or less equivalent and that levels.txt isn't creating big issue.

levels.txt was in the first PR that I opened in this subject in January 2018 (#86) and in the issue I've opened about the more-or-less current draft in October 2018 (#108).

[paulswartz]

But my concern is that now, in March 2019, we already have quite a few implementations done(MBTA, NY MTA, SF MTA, Google, London and some others stakeholders working on it). I don't know if all of them are supporting levels.txt (some might have no elevator, even if I doubt it). But it might be a bit late to change it if the two options are more or less equivalent and that levels.txt isn't creating big issue.

@mbta has a levels.txt (42 rows) in our public feed.

[paulswartz]

+1, though it would be nice to clean up the trailing whitespace before merging.

[abyrd]

+0. I am hesitant to block this change alone at the last minute, as I see that a large number of stakeholders are already structuring the data this way with a separate levels table. It would be helpful though if someone can explain why levels are broken out into a separate table. I do not see the two representations (embedded field versus reference to external table) as equivalent. The table option somehow implies that the mezzanine or basement level of two unconnected stations are the same entity. It would be preferable to make such a decision about the data model for a solid reason.

Fields stating the level directly (rather than referencing external tables) seem more readable, not significantly more voluminous, and closer to the reality of different stations being different entities.

[LeoFrachet]

So the vote passed!

5 votes in favor:

• Google: Alexej @aababilov & Dmitri @dbabramov
• Stefan @skinkie
• NY MTA: Kurt @kurtraschke
• Kisio: Pascal @prhod
• MBTA: Paul @paulswartz

One abstention:

• Conveyal: Andrew @abyrd

I'll fix the trailing spaces and the CLA and I'll merge.

[LeoFrachet]

Trailing spaces removed.

Alexej @aababilov can you force-approve the CLA? Thanks!

[aababilov]

cla: yes

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

[mmorang]

Can someone post a link to a complete GTFS dataset that makes use of these new tables? The examples linked above for Taverner's Hill and King's Cross have only a subset of the entire GTFS feed. I need a full dataset to do some testing for my tools.

[sdjacobs]

level_index is an integer in the spec here, rather than a float. Which is correct?

[paulswartz]

@mbta is treating it as a float, and we have some non-integer values already.