What about adding the following clarification for stop_access = empty, per this suggestion:

When its parent station does not contain any entrances/exits (location_type=2), data consumers should consider this stop as not part of the main station structure or enclosed area.

What about adding the following clarification for stop_access = empty, per this suggestion:

When its parent station does not contain any entrances/exits (location_type=2), data consumers should consider this stop as not part of the main station structure or enclosed area.

Do we have a good sense about how frequently producers include entrances for their parent stations? Even for us at the MBTA, we include them (and pathways) in full for our metro stations, but for the most part have not added them for our many regional rail parent stations. I'm not sure that the exclusion of station entrances, at this time, can imply one behavior or the other—after all, this ambiguity about the definition of a parent station is part of the rational for stop_access.

Of course, consumers will (and already do) have to make assumptions in those cases—from a survey in our market, it looks like OTP and the major commercial apps are mixed in whether they route involving entrance-less stations to the parent or the child.

How do you deal with the situation where a platform can either be accessed directly from the street, and also through the station building?

Your proposed changes to pathways will prohibit such usages from happening.

How do you deal with the situation where a platform can either be accessed directly from the street, and also through the station building?

Your proposed changes to pathways will prohibit such usages from happening.

@miklcct, could you provide (or otherwise illustrate) an example of such a platform?

What I can picture is a platform that is outdoors and right adjacent to the station building/doors—without seeing more, I believe this would simply be a stop_access = 1 stop, with routers using both pathways and the street network to facilitate transfers between this platform and other platforms contained within the station building.

How do you deal with the situation where a platform can either be accessed directly from the street, and also through the station building?
Your proposed changes to pathways will prohibit such usages from happening.

@miklcct, could you provide (or otherwise illustrate) an example of such a platform?

What I can picture is a platform that is outdoors and right adjacent to the station building/doors—without seeing more, I believe this would simply be a stop_access = 1 stop, with routers using both pathways and the street network to facilitate transfers between this platform and other platforms contained within the station building.

The PR says that

Directions for access should be generated directly to the stop, independent of any entrances or pathways of the parent station.

which implies that routers should not use the pathways at all, contradicting to what you have replied me.

There are also situations where the best route to access a stop is by using the station building, even if the stop is otherwise directly accessible from the street level, for example, there is a heavy rail line with two side platforms connected through the station building, but each side platform is also accessible directly from the street. If you want to access the platform in the opposite direction, you are better off using the station building instead of negotiating the general pedestrian network to find a way to cross the railway.

Also how can you model stations where there are multiple station buildings and not all platforms can be accessed by all station buildings / entrances?

For example, I have a station which contains platforms 1, 2, 3, 4, A, B and 3 station buildings, X, Y and Z.
From station building X, I can only access platforms 1, 2, 3 and 4.
From station building Y, I can only access platforms 2, 3, 4, A and B.
From station building Z, I can only access platforms A and B.

If you need to transfer between platform 1 and platform B, you either need to transfer through the street level by exiting station building X and entering station building Y, or through another numbered platform.

The PR says that

Directions for access should be generated directly to the stop, independent of any entrances or pathways of the parent station.

which implies that routers should not use the pathways at all, contradicting to what you have replied me.

There are also situations where the best route to access a stop is by using the station building, even if the stop is otherwise directly accessible from the street level, for example, there is a heavy rail line with two side platforms connected through the station building, but each side platform is also accessible directly from the street. If you want to access the platform in the opposite direction, you are better off using the station building instead of negotiating the general pedestrian network to find a way to cross the railway.

@miklcct Got it—my initial interpretation was that stop_access dictated only what the first (or final) segment of a transfer from (or toward) such a street-side child stop should look like, with the remainder of the steps up to the router's logic. I see how this could use some clarification, though, and I'd ask @tzujenchanmbd and/or @bdferris-v2 if any adjustments should be made, especially weighing in on how (or if) a stop_access = 1 stop should be treated differently from a location_type = 0 child stop today that has pathways running to and from it.

@miklcct for your examples:

There are also situations where the best route to access a stop is by using the station building, even if the stop is otherwise directly accessible from the street level, for example, there is a heavy rail line with two side platforms connected through the station building, but each side platform is also accessible directly from the street. If you want to access the platform in the opposite direction, you are better off using the station building instead of negotiating the general pedestrian network to find a way to cross the railway.

stop_access=1 wasn't initially meant for this case. If the rail platforms have pathway-level connectivity that can be modeled in the feed, including paths through the station building and paths to the external street, then I would indeed use pathways for that modeling and I would add explicit pathways + entrances onto the street grid (likely at either end of the platform), even if the platform is technically accessible from the street along its entire length.

I could maybe imagine specific handling for these mixed-access platforms via an additional stop_access enum value at some point in the future if there is sufficient demand, but it hasn't been a common (or even infrequent) pain point in our experience.

For example, I have a station which contains platforms 1, 2, 3, 4, A, B and 3 station buildings, X, Y and Z.
From station building X, I can only access platforms 1, 2, 3 and 4.
From station building Y, I can only access platforms 2, 3, 4, A and B.
From station building Z, I can only access platforms A and B.

stop_access=1 isn't really meant for this case either. I would still use pathways for modeling the combinations of platforms + building entrances for this station complex. For a transfer between platforms 1 and platform B, I think the router would see that there is no direct pathway and instead direct you outside to exit and re-enter the station complex.

For a transfer between platforms 1 and platform B, I think the router would see that there is no direct pathway and instead direct you outside to exit and re-enter the station complex.

@leonardehrenfried can you confirm the behaviour of OpenTripPlanner in such case? From what I have read OpenTripPlanner will always use pathways if they are available, only OSM data otherwise. In such case a transfer between platforms 1 and B will be possible by multiple pathways (from platform 1 to the station building, then platform 2, another station building, then platform B).

After further reading the proposal, I think that the proposal modelling is flawed. A better modelling is a nested stop_area.

Using London Paddington as an example, it isn't possible to model what I want in the current model. The station complex consist of the following parts:

• a National Rail terminal.
• two separate London Underground stations, one for Hammersmith & City and Circle lines, another for Bakerloo, Circle and District lines. They are separated by the National Rail terminal.
• an Elizabeth line station which is directly connected to the Bakerloo London Underground station, however, as Elizabeth line is National Rail, it belongs to the same station as the National Rail terminal in the National Rail network, but transfer between them isn't directly possible.
• A number of bus stops around it, named "Paddington station"
• A taxi station outside the National Rail terminal

Therefore I would like the "station cluster" alternative to be presented instead. For the typical outdoor bus stops scenario, it is also applicable because a rider will recognise the bus stops to be a stop area, the train station to be another stop area, if the passenger information systems are set up to be such. For a large rail station like in the picture shown, the 3 stops on the south-west of the train station should be in one stop area, and the single stop on the south-east of the train station should be in another stop area, where a bus may call at both.

It's worth noting that this PR isn't meant to solve all modeling issues with large station complexes, as noted by @tzujenchanmbd above in his three-phase plan. Station clusters are included in that plan.

But jumping ahead to that discussion, it'd been argued by me and others that we don't want to introduce arbitrary levels of station-stop clustering without explicit guidance on how it should be used, lest different data providers make up their own perhaps arbitrary modeling that might be more of a reflection of their own internal operations as opposed to how riders think about stations and stops. I've specifically argued that clusters should only be introduced for groupings most riders would recognize, want to see rendered at high zoom levels, and possibly search for by name (see the Alternatives Considered section of the proposal doc for more discussion).

Paddington is an interesting example that we've gone back and forth on how we model it on Google Maps but ultimately we agree that most riders would make a mental distinction between the overall Paddington Station complex and the individual Underground stations (with much arguing about the Elizabeth Line). But I don't think most riders would think of the Padding Station Bus Complex as a thing. My intuition is that they are just thinking of them as bus stops attached to Paddington Station. As such, I'm not sure they deserve their own sub-cluster within Paddington Station.

Of course, Paddington is one of the most complex examples. I think there are plenty of simpler examples of an underground station with one or two bus stops at street level that are more obvious applications of stop_access.

Thoughts?

Different transport networks have different modelling on what is a station, and present to passengers differently. Therefore I think that the GTFS should reflect that as well.

For example, in Citybus, stops are labelled with numerical IDs with an alphabetical suffix. Stops with the same numerical code belongs to the same "station", while in KMB, stop IDs are just labelled sequentially from the beginning of a street and can continue for kilometres, similarly for public platform codes on Nathan Road as well. Adding complication to the matter, some stops are shared between the two networks as there are a number of jointly operated routes as well, and there are instances where two stops belong to the same station in one network but in different stations in the other.

So the matter can become very complicated if different transport networks share the same stop or station, which already exists in cases such as Farringdon, Paddington, etc, and a multi-network GTFS is produced using some national standards for IDs (e.g. Naptan for the UK).

Going back to National Rail, in terms of passenger information and ticketing, the terminus and the Elizabeth line stations of Paddington are the same station with public code PAD, but operationally the Elizabeth line station has a substation code PDX, similar for Liverpool Street as well. And from the passenger's perspective, all these substation codes are a distinct part, clearly separate from the main station (these substation codes were created for passenger assist purpose to guide staff to the appropriate part of the station).

Paddington may not be the best example for bus stops having their own cluster, but Heathrow Central, Canada Water, Southgate, etc., are clear examples of that.

I will only support the proposal if it is written in a mode-neutral way and doesn't imply anything about physical infrastructure (as I would like to keep the option open for routers to use pathways even for stops outside station buildings, or to use the street network for stops inside a station building where indoor mapping is of a high quality in OpenStreetMap), but only as an instruction to the router how to generate routes (stop_access = 0 forces the router to use pathways, stop_access = 1 prohibits the router to use pathways).

@miklcct no argument that is complicated.

Are you still opposed to stop_access in all situations? You'd prefer using an explicit sub-cluster for bus stops in all cases?

@miklcct no argument that is complicated.

Are you still opposed to stop_access in all situations? You'd prefer using an explicit sub-cluster for bus stops in all cases?

I support its use only as an instruction for the router. No other meanings should be attached to it.

@miklcct I think we are aligned since that's the primary use case we want to support here as well (accurate walking directions between stops/platforms). But just to double check, what other meanings did you have in mind that you specifically wanted to avoid?

@miklcct I think we are aligned since that's the primary use case we want to support here as well (accurate walking directions between stops/platforms). But just to double check, what other meanings did you have in mind that you specifically wanted to avoid?

Any implications if the stop belongs to certain physical structures. None of the values should carry any meanings if the stop is indoor / outdoor / part of a building / interchange / complex / etc.

Which means the phrase in the PR like "is part of the station or enclosed area" has to be removed.

Btw, what should be the behaviour is a stop is specified as stop_access=0 but there is no path which can eventually reach an entrance / the station building? Is it allowed by the specification?

Also, I think we should allow the use of a pathway to a stop with stop_access=1 as well, which can be used to access another stop with stop_access=0 in the same station indirectly from the street. For example, a railway station with two platforms, and the only access from street is via one of the platforms and a footbridge to the other.

Any implications if the stop belongs to certain physical structures. None of the values should carry any meanings if the stop is indoor / outdoor / part of a building / interchange / complex / etc.

I hear what you are saying, but I think there is value in providing some guidance on when this is typically used. If we dropped from the "the stop/platform is part of the main station structure or enclosed area" language from the enum descriptions, is there room for some additional language like:

Indicates how the stop is accessed for a particular station, in order to produce accurate walking directions when the stop may be accessed independently from the main station station structure or area, including any explicit entrances.

Regarding remaining points:

Btw, what should be the behaviour is a stop is specified as stop_access=0 but there is no path which can eventually reach an entrance / the station building? Is it allowed by the specification?

Per the spec proposal text:

The stop is accessed via entrances and pathways of the parent station, if specified, or otherwise via the station itself.

Put another way, if there are pathways for a station, trying using those first. If a stop only has entrances but no pathways, route to a reasonable entrance. And if the station has no entrances or pathways, route to the station itself.

Also, I think we should allow the use of a pathway to a stop with stop_access=1 as well, which can be used to access another stop with stop_access=0 in the same station indirectly from the street. For example, a railway station with two platforms, and the only access from street is via one of the platforms and a footbridge to the other.

As I argued above, I think these would all be stop_access=0 stops, where you'd introduce pathways + an explicit entrance for the street-accessible platform. If we really wanted to support a mixed-type stop access explicitly, I'd rather do it with a separate enum value so that we can perform tighter validation of data.

Any implications if the stop belongs to certain physical structures. None of the values should carry any meanings if the stop is indoor / outdoor / part of a building / interchange / complex / etc.

I hear what you are saying, but I think there is value in providing some guidance on when this is typically used. If we dropped from the "the stop/platform is part of the main station structure or enclosed area" language from the enum descriptions, is there room for some additional language like:

You can give them as examples, but these wording should not be part of the specification.

Indicates how the stop is accessed for a particular station, in order to produce accurate walking directions when the stop may be accessed independently from the main station station structure or area, including any explicit entrances.

Regarding remaining points:

Btw, what should be the behaviour is a stop is specified as stop_access=0 but there is no path which can eventually reach an entrance / the station building? Is it allowed by the specification?

Per the spec proposal text:

The stop is accessed via entrances and pathways of the parent station, if specified, or otherwise via the station itself.

Put another way, if there are pathways for a station, trying using those first. If a stop only has entrances but no pathways, route to a reasonable entrance. And if the station has no entrances or pathways, route to the station itself.

Thank you for your explanation. You need to spell it out:

If stop_access=0, the stop cannot be directly accessed from the street network. It must be accessed from a station entrance if there is one defined for the station, otherwise the station itself. If there are pathways defined for the station, they must be used to access the stop.

Also, I think we should allow the use of a pathway to a stop with stop_access=1 as well, which can be used to access another stop with stop_access=0 in the same station indirectly from the street. For example, a railway station with two platforms, and the only access from street is via one of the platforms and a footbridge to the other.

As I argued above, I think these would all be stop_access=0 stops, where you'd introduce pathways + an explicit entrance for the street-accessible platform. If we really wanted to support a mixed-type stop access explicitly, I'd rather do it with a separate enum value so that we can perform tighter validation of data.

This is what I strongly oppose. If a 200 m long platform is directly accessible wholly from the street without a physical entrance, what you are saying will mislead the users to find a non-existent entrance when alighting the train. We can introduce another enum value that explicitly tells the router it can access either from street or from pathways.

P.S. I now start to think that this proposal is just a way for producers to work around poor OpenStreetMap data instead of mapping their stations properly. With good OpenStreetMap data, we don't need this proposal at all for a router to generate correct instructions to the stop, regardless of it being in a station / on the street / underground.

You need to spell it out

Seems fine but @tzujenchanmbd would need to update the PR.

We can introduce another enum value that explicitly tells the router it can access either from street or from pathways.

Noted, but unless we have a data producer lined up for this specific case, I'd propose to hold off on that for now.

poor OpenStreetMap data

Recall that there are many consumers out there who can't work with OSM due to licensing restrictions and data producers who can't/won't integrate for other reasons. Thus why GTFS entrances + pathways + this proposal exist in the first place.

Recall that there are many consumers out there who can't work with OSM due to licensing restrictions and data producers who can't/won't integrate for other reasons. Thus why GTFS entrances + pathways + this proposal exist in the first place.

I believe that it's only Apple and Google that don't want to use OSM. I think it's not a fair characterisation to call it "many".

I fully agree with the standpoint that OSM Foundation over reached with the ODBL. Given that there many governmental agencies must provide CC-0 or like data, I would expect such data to appear in GTFS.

+1 Aubin

+1 PVTA

+1 LA Metro

+1 from @interline-io

This clarifies a confusion that we've also heard as trip planners/routing engines have consumed pathways data produced by Interline's tools and clients. We will add support.

+1 from Google

+1 from ODPT (Association for Open Data of Public Transportation, Japan)

+1 from the french NAP transport.data.gouv.fr

+1 from Japan Association for Bus Digitalization （日本バス情報協会）

+1 Trillium

+1 from the MBTA

+1 from Actionfigure.

+1 from Aoimori Web Koubou（青い森ウェブ工房）

+1 from Caltrans

+1 from BART

The vote passed on 2025-09-22 at 23:59:59 UTC.

14 votes in favour and no votes against.

Votes came from:
Aubin (@miklcct)
PVTA (@jmchatton)
LA Metro (@matikin9)
Interline (@drewda)
Google (@dekaikiwi)
ODPT (@iniad-bessho)
French NAP transport.data.gouv.fr (@maxime-siret)
Japan Association for Bus Digitalization (@niyalist)
Trillium (@westontrillium)
MBTA (@jfabi)
Actionfigure (@caywood)
Aoimori Web Koubou (@umineko50)
Caltrans (@vevetron)
BART (@ffisherBART)

Thank you to everyone who participated!