Change the definition of location_type=1

[skinkie]

location_type=1 is currently defined as: Station. A physical structure or area that contains one or more platform.

Given that for anything like an entrance or generic node for an on street bus stop a parent_station would be required. I could argue that the wording of location_type=1 should be more generic. I would suggestion something like:

Group. A logical entity that contains multiple stops, entrances/exits, boarding areas or generic nodes.

Lets have a discussion with Noun should be used.

[gcamp]

Do you have an example of stop groups that aren't stations? For street bus stop where that would be useful I'm only thinking about BRT stations, but those are actual stations.

I've seen some agencies put stations for stops that are on the same intersection but at different street corners, but I would ague that should not be a group.

[skinkie]

...please ignore the 6(!) different data points, for two stops, my eyes hurt as well.

But I would like to know if these two stops form a station, so I could maybe have a single icon on the middle of the road at a higher zoom level. Draw a pathway between north and south stop using the pedestrian crossing.

I am taking the example as simple as possible. Because I would like to know if this should or must not be grouped.

[abyrd]

@gcamp in my experience it is very common to have multiple separate physical stops with the same name, logically considered to be one "stop group", but not united under one building or physically separate structure. My understanding of the question at hand is the following: in many places it's standard practice to group most or all stops into this kind of groups. A large number (perhaps all) stops are defined to be part of a cluster with the same name. It is a requirement or existing practice to reflect those logical stop groupings in transit data sets.

Should GTFS reflect these logical groupings in its own way (with stations, or some new location_type)? Or should logical groupings be discarded, and only physical stop groupings (station buildings) be retained?

[paulswartz]

Our (@mbta) current GTFS combines these into a single parent station, but we received feedback from Google that this was invalid according to the spec. To that end, we are planning to replace some of these children with recommended transfers: https://groups.google.com/forum/#!topic/massdotdevelopers/ncwdhif6DaI

I think keeping them as children is likely what riders expect, so we'd be in favor of a change like this.

[skinkie]

Could Google comment how an entrance for these things could then be modeled? Should there be two additional parents stations, one for each stop on both sides?

[LeoFrachet]

I agree with @paulswartz, I've heard in the past Google insisting on this definition limiting station to physical structure. @dbabramov or @aababilov, could you give us your opinion on this possible change of definition?

@abyrd, you spoke about "cluster" of stops. A while ago (on 2018-11-09) I wrote an "Open Question" exactly on that in the GTFS-Pathways document:

Q4. Bus stops and stations [2018-11-09, LF]

Should close on-street bus stops be grouped as a station? IMHO it should not, since a station should be physical structure, either underground or as bus terminal. Also because this grouping could depend of the service, and two bus stops will be in the same “station” for regular bus, and at the same time subsequent stops of a local bus line.

If agency want to group bus stops that they see logically connected, I would advocate to create a “cluster” concept, instead of extending the “station” concept to a blurry definition.

=> transfers.txt seems to be enough for now.

If there is a need to represent such cluster (hearing @skinkie, there is), and if Google wants to keep location_type=1 as they are, we could define cluster with a new location type, which could be parent either of stop (if they do not belong to a station) or of station.

[LeoFrachet]

Oh and also we have been working (Google & MobilityData) on a document describing how to model stop and station. We were planning to submit it to the community next month, but since it is exactly the conversation we are having in this thread, here it is:

https://docs.google.com/document/d/1zQ2SEHh3Uvv3kkmOoeMCCSzyS5ny5_ZPQyS2gG0yVk0

[skinkie]

If there is a need to represent such cluster (hearing @skinkie, there is), and if Google wants to keep location_type=1 as they are, we could define cluster with a new location type, which could be parent either of stop (if they do not belong to a station) or of station.

Do you see now why I find it strange that a stop (on its own) can't be the parent_station of an entrance?

[antrim]

The current definition for location_type = 1:

• 1: Station. A physical structure or area that contains one or more platform.

"Platform" suggests this applies for rail stations, rather than modes like buses or ferries. What about bays in a bus station or docks in a ferry terminal? I suggest we modify the spec to make this mode agnostic.

Example to consider -- RTC Washoe's 4th Street Station (Transitfeeds link) in Reno, NV:

https://goo.gl/maps/82tpDgin7NvyzVKh6

[LeoFrachet]

+1 as long as the bays/platforms/quays are in a building or area under the control of the agency, aka it will be only closed on the decision of the agency, and not because the city is doing construction in the street.

[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.

[skinkie]

Keep open.

[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.

[derhuerst]

still relevant