Location_type=4 used in stop_times.txt?

[Stefan de Konink]

From the spec;

stop_id ID referencing stops.stop_id Required Identifies the serviced stop.
All stops serviced during a trip must have a record in stop_times.txt.
Referenced locations must be stops, not stations or station entrances. A
stop may be serviced multiple times in the same trip, and multiple trips
and routes may service the same stop.


Given that location_type=4 (boarding area) is not a station or a station
entrance, can it be used for scheduling? If not: why would one define a
boarding area?

--
Stefan

[Jeff Kessler (Keolis Boston)]

No, they're not to be used for scheduling, but are there to augment details for trips that have multiple boarding/alighting areas at a given stop (particularly rail). As an example, a trip may service a specific stop/platform, but that platform may have distinct boarding locations — akin to entrances — for:

• Coach numbers (where assigned seating is used)
• Accessible boarding locations
• Premium / first class coaches
• Quiet Car boarding locations
• etc.

This is elaborated/confirmed in the spec's description of stops.stop_name:

When the location is a boarding area (location_type=4), the stop_name should contains the name of the boarding area as displayed by the agency. It could be just one letter (like on some European intercity railway stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head of short trains” (Paris’ RER).

[Stefan de Konink]

On Wednesday, July 21, 2021 3:04:46 PM CEST, Jeff Kessler (Keolis Boston)
wrote:
> *When the location is a boarding area (location_type=4), the stop_name

> should contains the name of the boarding area as displayed by the agency.
> It could be just one letter (like on some European intercity railway
> stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head

> of short trains” (Paris’ RER).*

If the above is the case, the parent_station of such boarding area should
refer to location_type=0 (stop) otherwise, one could have multiple boarding
areas with different types all under a parent_station that groups them by
the entire station. Hence, this does not make sense.

--
Stefan

[Stefan de Konink]

There was a nice ticket already asking for clarification.

<https://github.com/google/transit/issues/188>

--
Stefan

[Jeff Kessler (Keolis Boston)]

> If the above is the case, the parent_station of such boarding area should refer to location_type=0 (stop) otherwise, one could have multiple boarding areas with different types all under a parent_station that groups them by the entire station.

Agreed, and this is already identified in the description of stops.parent_station:

Defines hierarchy between the different locations defined in stops.txt. It contains the ID of the parent location, as followed:

- Stop/platform (location_type=0): the parent_station field contains the ID of a station.
- Station (location_type=1): this field must be empty.
- Entrance/exit (location_type=2) or generic node (location_type=3): the parent_station field contains the ID of a station (location_type=1)
- Boarding Area (location_type=4): the parent_station field contains ID of a platform.

> Hence, this does not make sense.

Is the comment that stops.parent_station should be updated to "of a stop," that stop_times.stop_id's description should state it must correspond to a stop whose location_type=0/Null (as described in the link), or both?

[Stefan de Konink]

On Wednesday, July 21, 2021 10:19:44 PM CEST, Jeff Kessler (Keolis Boston)
wrote:
> *Is the comment that stops.parent_station should be updated to "of a stop,"

> that stop_times.stop_id's description should state it must correspond to a

> stop whose location_type=0/Null (as described in the link), or both?*

I think adding the location_type=0, would certainly make things more clear
(opposed to the not exhaustive list).

--
Stefan