Proposal to explicitly allow entrance/exit to be coupled with a non-station stop #129
Conversation
…tation stop. This would allow that an entrance to a track without a physical station structure can be modelled in implementations that are not aware of pathways.
|
Am I correct in thinking what you are proposing is:
|
|
@harringtonp I am extending the "must also contain a row for this station with location_type=1" with location_type=0. |
|
Proposal makes sense. |
|
This would make our lives a bit easier @mbta, as we have many stops which are currently modeled as a single stop ID. It would be nice to add entrances for them without having to completely remodel. |
|
The proposal looks quite good to me, however, see the following example: Platforms 1–3 can be accessed from all the orange entrances via yellow underground corridor, but then there is Platform S in the lower left corner with the only entrance from public bridge above:
Maybe it should be explicitly noted that if a stop has a direct entrance (or entrances), those linked to the parent station must not be considered to access to that stop. At least that's how I would understand it if we decided to merge these (now two separate stations in GTFS) into one station – but Google Maps do it anyway because of their almost same name. Some clarification would also be needed on the wheelchair_boarding field. On this occasion, I propose some more elaborate edits so that step-free routing can be more accurate even without the Pathways extension. The specification could newly describe a case where passengers on wheelchair can transfer between opposite tracks (represented by two stops) on an island platform, but cannot exit the station, as well as transfer only on one platform with direct non-accessible entrance. It would still fail in two cases, which I believe can be correctly represented only with the Pathways:
|
|
Hi, Stefan, Please could I ask a few clarifying questions:
Thanks. |
If the situation exists where the entrances wouldn't connect other tracks. I would suggest to declare multiple entrances at a single location (to facilitate linking the stop to the streetnetwork). Because otherwise normalisation would require generic nodes.
But if the station is in fact a station having multiple entrances where all tracks at some point do connect with eachother (but require a longer walking time) the multiple entrances for location_type=1 is obviously as possible.
Could you rephrase. Do you mean pairs between entrances? I would say that entrances should be linked to the streetnetwork, and that the connections between entrances can only happen if there is a route over the streetnetwork and/or shares the same position with another entrance.
I can only refer to the size of the document that describes pathways, with respect to lifting this single constraint in stops.txt. |
Let me know if I understand this correctly: For your illustration of a station with platforms S1 and S2, each connected to entrances E1 and E2, and a separate platform S3 connected to entrance E3, your suggestion is duplicating entrances E1 (E1.1 and E1.2) and E2 (E2.1 and E2.2). The station structure is going to look follows: stops.txt
My question is about connections between the pairs of platforms. Should these instructions be:
Your proposal does not appear to offer a way of disambiguating these two cases. Certainly routing apps could make educated guesses about platforms being connected to same exits. On the other hand, your proposal makes it more difficult by requiring that exits be duplicated.
I would not necessarily think of the length of the document as the main criteria for judging alternative proposals. As I see it, the pathways proposal is indeed long and complex because it attempts to describe a wide variety of properties, including e.g. accessibility and walking instructions. Simple cases, such as describing the structure of a station above, can be quite trivial, without ambiguity or need for guessing/interpretation: stops.txt pathways.txt Complex cases can be handled by creating generic nodes. My concern about your proposal is that it appears to handle one really simple case: a station with two platforms that have separate exits. Please let me know if you disagree, but I see the following limitations of this proposal:
Therefore I would be hesitant to support it. Thank you. |
Agreed.
The above parent_station would only work if the constraint holds that if entrances at stop level are provided the entrance to the stop must be used to enter the stop.
In your example stops.txt S1, S2 and S3 form a parent_station. Given that instruction I would normally say that without any inference the instruction could already be "Walk to platform S2", it would be the most naive approach an application could take. But given all the possible inference where E1.1.inside = E1.2.inside = E2.1.inside = E2.2.inside it could be fully that S1 and S2 are bound by the same pane. A more interesting case would be S2 to S3. S2->E1.2, E1.2->E3, E3->S3 can be deduced even without linking it to the streets. While it would also safe to say "Walk to platform S3". But it can say exit at E1.2 enter E3... The problem with the deduction is shown in the very first example that I posted. Unless the streetlinking is available, the fact that the rail tracks can't be crossed is not encoded. So without transfers.txt the distance between opposite entrances is unknown. But in all cases the fact that you would have to transfer from a Stop to an Entrance the situation should always improve if you would draw the route on a map with only the contents from stops.txt. And with the use of the entrance information the track to street linking significantly improves.
Duplication is accepted for multiple objects in GTFS, most prominently trips and service_id for non-continuous periods. It just makes generation and reading more simple.
Lets please deepen this case by the above semantics and ask ourselves the same question as you did. How is S1 to S2 rendered in text. Based on this information, how you reply? And the same for S2 to S3? Would it go via entrance/exit or not?
The primary reason for this proposal is allow any agency to improve stop to streetnetwork linking. It does not aim to materialise connections, transfers.txt would be retain that functionality, albeit it can have a higher precision. Attributes such as accessibility are supported, wheelchair_boarding would be fine for an entrance/exit. The proposal is not in competition to pathways.txt if agencies are willing to offer high detailed walking instructions those can be still provided. I would even say that it would complement pathways.txt in a way that it makes more sense. Only make references to the parent_station if it physically in the same complex otherwise relate to the tracks. This would still allow an entry in pathways.txt for more detail. |
That depends on what the client application wants to say. ...
The explicit pathway between S1 and S2 indicates that there is a link between S1 and S2 that does not require existing and re-entering the station. In the basic case the instructions for walking from S1 to S2 would be "Walk to platform S2". On the other hand, the absence of pathway between S1 and S3 indicates that the passenger must exit the station and re-enter it in order to make the transfer. Instructions may explicitly indicate a specific exit/entrance pair to take to make this transfer quicker, if required (pathways.txt may provide specific instructions on how to walk between entrances and platforms). ...
Thanks for the explanation. Unfortunately I do not quite see how this proposal complements pathways.txt I do not think that the complexity of the pathways specification is a good excuse to provide another way of doing the same thing, just because we want to save agencies time reading the full spec. I believe that examples matter more that the simplicity of the spec. I would oppose creating a hack in the spec specifically for handling a trivial case for the following reason: In my opinion having multiple ways of doing the same thing is a shortcoming of the spec, which already creates plenty of confusion for both producers and consumers. |
|
Thanks @skinkie for the detailed proposal with illustrations. There is some good discussion going on here. I agree that this entrance information is very important for routing and we need a simplified way to express it, as many producers are not going to micro-map their stations and in any case we do not yet have tools for doing so. To summarize the proposal and background (for any new readers): The pathways proposal has been around for a long time (since 2010) and was never truly integrated into the GTFS spec. However, subsets are used by some producers, accepted by Google, and accepted by some non-Google software like OpenTripPlanner. That original proposal has separate sections, one introducing location_type=2 (entrances) and another introducing pathways.txt which ties entrances to stops. These can be considered separate proposals, with pathways building upon entrances, since entrances can be associated with stations using the parent_station field rather than pathways. There is a big discussion going on elsewhere about the details of the pathways.txt proposal. This is essentially aimed at micro-mapping stations including turnstiles, elevators, hallways etc. It is likely that debate will go on for a while and it seems increasingly concerned with covering the small percentage of edge cases and agencies that will micro-map their stations, while 8 years after the initial proposal we still don't have a formally accepted mechanism covering the vast majority of use cases: simply associating an entrance with a platform or set of platforms. My understanding of @skinkie's proposal is to entirely bypass usage of pathways.txt and rely only on the location_type=2 proposal for a larger number of simple use cases, including not only the case where entrances are connected to every stop in a station, but also cases where entrances connect to only one stop, or a subset of stops in a station. This proposed change does a good job of covering one additional case beyond the basic case where all entrances connect to all stops in a station. But why cover just this one use case, and at what point do we stop adding workarounds to cover additional use cases? I see red flags in all the discussion here about inference rules for determining when transfers can happen between platforms, when you have to exit the station etc. The proposed change also starts bending the meaning of parent_station and feels a bit like a workaround. Note that stops like the Leidschendam example are also part of stations. Ideally the data set would unambiguously associate entrances with specific platforms and also group all the platforms and entrances together into a single station. I guess the idea is to sacrifice direct association of entrances with stations, in order to simplify the association of entrances with specific platforms (stops). Because those platforms are part of a station, transitively we can deduce that the entrances are also part of that station. Again it feels like a workaround that bends definitions and could lead to a lot of inference rules and heuristics. About complex cases like @jakluk's where one platform is accessed from a different entrance than all the others: properly modeling this as one station would require pathways.txt. This case would have to be modeled as two different stations to benefit from @skinkie's simplified model: any rule about direct entrance-to-stop connections overriding inheritance of station entrances would enable certain cases (like yours) but break other cases. Another possible solution to properly represent this while keeping a simplified non-pathway representation is to allow hierarchically nested stations, so there is one big station complex containing two stations, which then contain platforms (stops). But I believe the idea of hierarchical stations has been rejected elsewhere in the interest of simplicity. Considering all this, I tend to agree with @dabramov's commentary. I understand his hesitation to create multiple ways to express the same thing in GTFS, especially when it is essentially a workaround for the governance issue of finalizing a simple core pathways proposal. The pathways proposal is long because people are adding a lot of things to it. But following the 80/20 rule we should probably split off a core pathways proposal that covers the vast majority of use cases. I think there is a core of pathways.txt that everyone can agree on, which allows connecting an entrance directly to a platform and platforms to one another with no intermediate nodes. Indeed all other extensions to pathways are essentially space optimizations, because you can always provide decent routing information by including NxM pathways from the N entrances of a station to the M platforms (though there are some details to work out about implicit pathways created by station membership). @skinkie and @dbabramov should we just concentrate on articulating and pushing through that core pathways proposal? The fancy micro-mapping version of pathways.txt could just build upon it. |
|
Thank you very much for the great summary of the discussion, Andrew! You made a really good point about the current discussion of the pathways spec. Cheers! |
|
Maybe some update on the GTFS-Pathways proposal would be useful. First and for most, GTFS-Pathways isn't about micro-mapping at all. It's heavily schematic, allowing merging of sequence of ways to get only the structure of the station. Even the lat/lon are optionals in the current draft. If you (@skinkie and @abyrd) still see it as ("fancy") micro-mapping, I understand why the proposal above is made. Andrew (@abyrd), you said:
By reading that, you give the feeling that since 8 years people are arguing in a never ending conversation about edge cases. This is a pretty odd way of describing GTFS-Pathways. The current proposal has been build in maybe 3 or 4 months in Fall 2017 (and it's, beside the name, far away from the one made in 2009). Since then the core draft hasn't changed, we're working on adoption. After 6 months of silence, we've looked for early adopters last summer (summer 2018), and we have currently three agencies (MBTA, SFMTA, NYMTA) gathering data according to the current draft. Agencies are ressource limited and cannot map their network in one night. But I would be tempted to say that we've reached a consensus on the proposal and that we are currently at the implementation phase of it, and not that it's been 8 years and we're still debating edge cases. Stefan (@skinkie), you said:
Let's speak about it. The document is 40 pages long, with 28 pages of examples (including one step-by-step example, with pictures, drawings & schema, which is 10 pages long). The Us, the happy few talking about specification on GitHub, might be used to deal with dry and technical specification, but helping interns in agencies understanding it, agreeing on best practices, lifting the interpretation ambiguities and agreeing on a common level of granularity require a bit more than the a dry spec. Also, a big part of those pages are schemas and data samples. Interestingly enough, the proposal above triggered some very long comments by @skinkie and @dbabramov, with schemas and data samples. Most (maybe all) the edge cases that this proposal is triggering have already been discussed and solved by GTFS-Pathways. So yes, I do think that the roadmap it to keep on helping agencies to build GTFS-Pathways datasets, listening to their needs and issues. Once they'll have done it, only the used fields will be offer for adoption to the GTFS spec, and it will be a small subset of them. |
|
If you want a short and core GTFS-Pathways proposal, with just the few commonly used fields, I can build it easily, just ask. But I would try to avoid multiplying the docs and the discussions. |
Lets speak about it indeed. GTFS-Pathways is basically (in size) a new standard, especially if you would compare it to GTFS itself. If you would compare the only change I propose that would allow a direct entrance to a stop, instead of a parent_station you must be very strong minded if you would still state that this minor change with great functionality is a bad change in the core standard. In my humble opinion pathways could even benefit from it. Since it is a new standard (and I personally don't like competing standards in this case NeTEx, OpenStreetMap, OpenLR, GTFS, etc.) I would rather have something that could work tomorrow without the hassle for everyone to adopt a new standard and introduce a parent_station for every stop that is touching a road. Effectively a 33% increase of stops.txt, without having added a single entrance. |
barbeau
added
the
GTFS Schedule
|
This pull request 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. |
stale
bot
added
the
Status: Stale
|
This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process. |
The implementation of pathways goes into a discussion that will lead to a very complex standard and would certainly mean that operators require a separate topology editor to enhance their feeds. Many operators do have entrances and exits available but they are currently limited by the dogma that entrances would only apply for station like structures.
Outdoor stations with stairs and escalators have no single entrance or exit to reach both tracks but instead have an entrance that would go directly to the track. If the station is bundled via a parent_station the two entrances would suggest both tracks can be directly accessed via any entrance, which is not the case. This proposal would allow an entrance directly to be coupled to a track, without going via a physical station structure, and can be modelled in implementations that are not aware of pathways.
Systems that are not compatible to add entrances to stops should warn that the optional data can't be processed. Given the low number of systems that produce entrances and therefore consume I would like to explicitly ask for any system that would fail on this change.
This proposal allows: