Missing functionality to define "conceptual grouping of stops/stations" in existing GTFS

[tzujenchanmbd]

Context

Recently, community members from Asia, Europe, and North America have pointed out the current GTFS missing functionality of defining conceptual grouping of stations/stops (or lacking "another-level" of hierarchy of stations/stops (Station cluster))

Here are some relevant discussion records recently:

• Thread #1 in gtfs slack channel
  
• Thread #2 in gtfs slack channel
• 2024-02-27 GTFS Fares v2 working group meeting note
  

Members from the Association for Open Data of Public Transportation [ODPT, JP] and the Japan Bus Information Association have also brought up this issue to us.

Issue

According to the current specification, location_type=1 is "station" (a physical structure or area that contains one or more platforms). This hierarchy doesn't provide functionality for defining station/stop grouping that riders conceptually think of it.

Based on the information we've gathered, having a new mechanism could be beneficial for the following use cases:

1. Directing via station entrance or directing via street networks
   For example, There are a train station and multiple adjacent bus stations on a public street, and they can share the same or similar station names. According to the current description of location_type=1, it seems these adjacent bus stops should not be included within the hierarchy of this train station (parent_station). When these bus stops are independent, consumers can correctly direct riders using the street network, rather than mistakenly guiding riders to use entrances(and pathways). However, this approach may have some drawbacks, such as:

• Confusion in search results when bus stops share the same name as the train station.
• Unable to set service alerts for the entire conceptual group.
  
  On the other hand, some producers may include these bus stops within the hierarchy of the train station. However, doing so will lead consumers to give riders incorrect directions (using entrances and pathways).
  
  The current GTFS lacks a mechanism to define this conceptual grouping while also able to distinguish whether riders need to pass through an entrance. This could potentially be achieved by adding a field or introducing a higher-level hierarchy (station cluster).

2. Searching and visualization
   Considering another example: there are multiple adjacent heavy rail stations with their own physical structure and entrances. They serve different routes/agencies and have the same station names. The current GTFS cannot define this station "cluster" that have a higher-level conceptual grouping. When riders search for this station name, consumers may provide them with an incorrect station, causing confusion.
   
   In this particular example, a higher-level of hierarchy (station cluster) seems necessary if we want to group these stations together, since each of them also serves as a parent station for their own entrances and stops(platforms).

3. Service alerts
   Producers can directly set service alerts for the entire conceptual group, such as the entire train/subway station complex or multiple adjacent bus stops with identical station names.

4. Effective Fare Leg
   When the fares v2 working group discussed rules for treating two or more legs as a single leg for fare calculation purposes, we considered how to formulate station-related semantics, how to include stop pairs, and different modes. A functionality of defining conceptual grouping might help to formulate fare_leg_join_rules.

Please share any examples for the above use cases, any other relevant use cases, which use cases are more critical for your region, or any other thoughts here.

[tzujenchanmbd]

The above comment states

location_type=1 is "station" (a physical structure or area that contains one or more platforms). This hierarchy doesn't provide functionality for defining station/stop grouping that riders conceptually think of it.

There might be arguments on this statement as well. (E.g. the word "area" implies it can support conceptual stations/stops grouping?) We would also like to learn how the community interpret the current location_type=1.

[leonardehrenfried]

I've experienced variations of this problem before and while the extra layer of hierarchy seems tempting, my favourite solution would be to widen the definition of "station" to include anything that a producer sees as a "group". That definition may vary from place to place and producer to producer. Personally, I've started to interpret the "area" part of the definition that way for a while.

For example, some places may want to place two bus stops on either side of the street servicing the same routes as a station so they can send service alerts this group.

The problem with the pathways/entrances I would solve by explicitly adding pathways from inside the physical rail station to the bus stops outside.

Why isn't the extra layer of hierarchy my preferred solution? Netex has this and I've rarely seen usecases that were relevant for a passenger.

[skinkie]

Why isn't the extra layer of hierarchy my preferred solution? Netex has this and I've rarely seen usecases that were relevant for a passenger.

If you model different modes in different stations, like the Germans do, it is something you cannot avoid. That this practise doesn't happen in NSR, that is because the model is too simplistic.

[jspetrak]

I would consider it be a "point of interest". Let's say there is "Vienna Airport" but it has separate bus and rail stations having each unique ID in the station registries and slightly different names. Each of these stations further has stops to represent platforms or bus stops.

[magnusburton]

I have thought about this issue too. In Stockholm, Sweden, the regional GTFS data for the operator SL contains three different parent_stations with the same name and different stop IDs.

Station ID A, Slussen contains ferry stops
Station ID B, Slussen contains bus stops
Station ID C, Slussen contains the metro

All of these IDs should, by local knowledge, be considered the same POI: Slussen. The transfer times between the different stations may be 10+ min, but when searching for Slussen, one expects an union of the three stations to be presented.

[jfabi]

@leonardehrenfried My concern with simply clarifying an expanded definition of a parent station is the guidance for pathways that "[p]athways must be defined exhaustively in a station". This would suggest that pathways would also be needed from bus stops outside a station building to the rail platforms inside, which can result in incorrect journey planning.

At the @mbta, our current practice for bus stops adjacent to rail stations is: Leave the bus stop out of the parent station if it is on the side of a public street, but include the stop in the parent station if it is in a dedicated busway (with no mixed motorized traffic). Already this leads to suboptimal trip planner behavior for bus journeys originating at stations with busways. Take the example of our station Malden Center:

In the first image above, the ground floor of the station building and indoor waiting area (the rail tracks are elevated) is outlined in green, with the entrances to the building in purple. The three bus stops are all considered part of the rail parent station, though they are also alongside the neighborhood sidewalk network.

In the second image above, a trip from the nearby neighborhood onto a bus gets routed via the nearest station entrance, making for a circuitous journey.

Shifting the entrance locations to be along the street-side sidewalks would help, but would also then deviate from our riders' colloquial understanding of the station entrances. Perhaps, as a compromise, there is some designation we could add onto stops or pathways to say that using pathways is not required to access the stop?

[leonardehrenfried]

I have been thinking about the examples presented here and I'm kinda shifting my position.

The pathway argument in the last post and the Vienna airport example are good arguments for having an additional layer of hierarchy. I like the POI framing which is detached from any physical infrastructure.

[kurtraschke]

This is something that would be useful for the New York City Subway as well. We have a multi-level hierarchy of station complexes and stations which cannot be fully modeled in GTFS. In our static GTFS at present, for every "station" (which is a somewhat abstract concept which does not precisely map on to real-world expectations of what a station is), we define the parent station and two child stops, representing the northbound and southbound platforms (an abstraction which breaks down at stations with more complex platform layouts, but that's for another discussion).

However, from a business domain perspective, the hierarchy does not end there. There are three locations where a single "station" actually has two GTFS parent station IDs (West 4 St, 145 St, and Queensboro Plaza), and then these stations can be aggregated into "station complexes" at some locations.

(Note that this depicts an arbitrary scenario that does not exist in real life at any station complex; it is merely intended to show the hierarchy of entities and how they nest within each other.)

At present we maintain several control files external to GTFS (specifically our Stations, Station Complexes, and Stations and Complexes Open Data datasets) which define these higher-level entities; third-party consumers can consume this information at their discretion but it is not as readily available nor as legible as it would be were it to be integrated directly in our GTFS.

(Yes, we could "solve" this by transforming how we model stations and complexes in GTFS to flatten out the hierarchy, but this would have complex interactions with many internal and external systems and it is unclear whether such an undertaking would even be feasible.)

[skinkie]

Regarding your description, it feels to me that the GTFS Station is a grouping of the conceptual stop area (stops in opposite directions) while the station complex was the original intention for the GTFS station.