GTFS-BoardingRestrictions #117
Comments
|
On donderdag 8 november 2018 19:28:26 CET, Leo Frachet wrote:
GTFS currently cannot represent such limitation.
It can, by implementing multiple trips, having boarding restrictions on all
other stops than the stop the limitation is for. Fully backwards
compatible.
The proposal is to normalize an existing practice: the
stop_time_limitations.txt extension defined by Bileto
***@***.***). Here is the proposal:
bit.ly/gtfs-boarding-restrictions.
Thoughts?
Unless an algorithm is included to convert the limitation into something
that a journey planner can work from (positively defined, instead of
negatively defined) this idea will not get my support.
…--
Stefan
|
|
@LeoFrachet this sounds like the infamous (among journey planner developers 😁) French rules disallowing local transport to certain operators. The document from @jspetrak shows this also exists in the Czech Republic. I am curious though, does such a thing actually exist in most other places? This seems like a construct that would only be created by ad-hoc regulations. Even though I have a personal interest in covering French transit data well, I would be hesitant to add an entire new file to GTFS to allow such a special rule to be represented concisely. I know there's a push to represent every detail in GTFS, but we should consider whether such details will ever be handled by the majority of consuming software, as well as the implied workload of revising every consuming application. We should be cautious of GTFS drifting into a less organized approximation of Netex. It seems to me that there is a need for more RFC-like "provisional extensions", where a group of 2 or 3 producers agree together to add a certain file or field to their GTFS feeds and maintain a common specification document, but this is only referenced from the main spec as a provisional extension. A good example of this was pathways.txt. This can allow a group of producers and consumers of the extension to build up over months or years, and allows us to judge the utility and fitness for purpose of the proposal before it is officially voted. |
The problem with this is that it's an N^2 expansion of each trip. Of course the consumer will have to somehow produce such an N^2 expansion anyway... but it seems inefficient to represent it that way in the source data. It would also hide the fundamental unity of all those trips, which are in reality served by a single vehicle. |
|
On vrijdag 9 november 2018 06:06:45 CET, Andrew Byrd wrote:
The problem with this is that it's an N^2 expansion of each
trip.
- (N-1)
…--
Stefan
|
|
I agree with @abyrd (as a French data consumer :) ). This problem with duplicating trips is not only for journey planning: when providing time tables or next departures at a stop, duplicated stop_times will appear... Duplicating trips will also implies difficulties with GTFS-realtime TripUpdates. |
|
@prhod Duplicated tables will not happen, because there is only a single pickup for each exception defined. |
Ah right, each trip expands into one trip per zone it traverses. This trip e.g. allows pick-up at all stops in zone A, and drop off in all stops in other zones except A. So there's not a quadratic space issue, and any one stop would only have one expanded trip with the pick-up flag enabled. Still multiple trip entities per actual vehicle trip, which could potentially confuse consumer applications. But this is in fact a guideline on how to expand these (hopefully rare) situations into trips that can be interpreted by most routing / travel advice GTFS consumers. |
This is moderately common among intercity carriers in the US, where there are very often agreements with local transit authorities to not market trips that are entirely within a single agency's jurisdiction. The management of such data can be pretty complicated from the producer side. It's not so much the number of extra trips that need to be built, but rather, the complexity of determining what extra trips are needed, especially when there are a few different boarding rules along a pattern. |
|
@abyrd As far as I have the knowledge of timetables, I could provide following real-life examples:
Ad 1. I have already provided examples from Czechia, that is also common for Slovakia Unfortunately, two biggest GTFS datasets from Czechia (PID, IDS JMK) are both from organizations managing system of subsidized public transport that does not have these limitations. They have the trips being protected. So I can't provide any example how the transformation was solved hear so far. Let's say, we have roughly 12K licensed bus routes in Czechia from which roughly 1/3 is commercial. And more than half of those commercial bus routes is somehow limited using the boarding restrictions. @LeoFrachet Could you provide some example of French timetables? I am curious about their solution of these limitations. We did not opt for multiple trips for single trip with restriction at Bileto because we use the GTFS data internally to represent trips for making bookings. Having multiple trips for single vehicle means a lot of work not to have duplicate seat reservations. |
|
A few different topics are being discussed (which is great), let's try to address them one by one. Duplicating the trips@skinkie said:
@skinkie suggests to duplicate the trip. I agree with what @abyrd said: it's inefficient, and "It would also hide the fundamental unity of all those trips, which are in reality served by a single vehicle." Also, how to handle real-time feed then? We will have to provide n-1 times the same vehicle position? And to provide n-1 times the same ETA at the last bus stop of the trip? In my DC-NYC-Boston example, this would also lead the riders to think that they're taking an express bus to Boston when they board downtown New York. Riders will get confused when the app tell them there is no stop until Boston, and the bus starts to stop with people boarding and alighting. And if they ask the driver if they are boarding the express to Boston, the driver will say no. This is IMHO a hack, not a proper way to describe the data. Use cases@abyrd said:
Hum, I don't know what make you assume my request is specifically for French data (by baguette accent maybe?). The request originally came from North American stakeholders for North American intercity bus trips. As @thomastrillium said, "this is moderately common among intercity carriers in the US". According to @prhod this is indeed also happening in France, and according to @jspetrak it's also happening in CZ. @skinkie: do you have such examples in NL, BE or DE? We already have at least 3 countries where it's happening (CZ, FR & US). So I do think there is a need to represent such data, but I hear you concerns about backward compatibility. Backward compatibility of boarding limitations@abyrd said:
This is big pain point that we have to discuss, I agree. We have two ways to handle it, depending on what would happen for GTFS consumers who wouldn't change their code:
This is a good question for consumers, what do you prefer? @dbabramov, @saraemarcus, @juanborre, @slei. |
GTFS is inefficient. It has no normalisation, and it is not using the method that is proposed to group things in any other structure. GTFS is explicit, and being explicit it can be directly consumed without interpretation. There is a single realtime feed for the group of trips, because all trip share the same realtime_trip_id.
What do you mean here? In your method you are also preventing a drop off. Would your method make your riders think they are not taking an express bus? Your argument doesn't make any sense. The drop off is in my method not allowed, but the full pattern is provided, there are no stops missing.
Again, I challenge you to come up with an algorithm that makes your proposal explicit for a journey planner to work with. Until you do, you are just designing a cathedral.
Germany, The Netherlands... |
|
|
Custom extension for GTFS+ and the Dutch feed. |
proposal B - stop_times_limitations.txtWith proposal B, I'm confused about the purpose of I noticed that proposal B has also changed to remove the new stop_times.txt pickup_type and drop_off_type values, but it is still unclear how these new limitation rules interact with existing pickup_type and drop_off_type values. Do the existing values prevail always, and the limitations only apply on top of them? As mentioned by others, I'd like to see pseudocode on how these limitations are to be interpreted. This seems like the ideal proposal, though not necessarily the most pragmatic. proposal C - duplication of tripsWhile this won't result in duplication of trips on departure boards, it will on arrival boards, and therefore any attempt at trying to construct timetables for routes. Arrival boards are useful in cases when a vehicle is passing through, to reassure riders waiting at a stop that they haven't missed their service. This proposal may also imply that a stop is the start of the trip, when it is in fact not. Arguably these are minor use cases for most consumers, and the benefit of having things 'just work' in existing consumers is worth considering. That said, I don't think this is a viable proposal until there's a way to link these trips together somehow to indicate they're the same trip in real-life, so we can identify these trips if necessary. backwards compatibility for proposal BGiven the option of either forbidden journeys displayed, or not displayed, not displaying them would be preferable from the consumer/rider perspective - there's no chance they'd accidentally board a service they can't disembark from. I'm not a fan of requiring pickup_type & drop_off_type to be 1 when a limitation exists though - it means changing two files and could easily lead to producers adding a new stop sequence to stop_time_limitations.txt and forgetting to update stop_times.txt. It seems to make more sense that when using limitations, all the limitations are specified in the one file. However, I can't think of any other option to handle this without adding unwanted baggage to the spec, so displaying them regardless may be the way forward. In general, some kind of spec versioning in the dataset may be the way forward, so that it can at least advise on compatibility. |
|
About option C (duplicating trips), @slai said:
Indeed. I fully agree. And therefore I went back to the drawing board to try to solve this. The spirit being that those duplicated trips are distinct commercial trips, but served by the same physical vehicle. Came out of this work an option C under steroid, called the GTFS-VehicleIds proposal. Based on this concept of defining which vehicle serves which trip, and by defining 3 new fields (
I let you read and comment: http://bit.ly/gtfs-vehicle-ids |
|
Thanks to some comments above, we have confirmed that boarding restrictions are a common thing in several countries. They need to be represented to provide customers with good trip plans. Expanding a single trip into multiple trips in the source data strikes me as a workaround though - perhaps a good stopgap solution but not something that should be done by deliberate design. It does not seem wise to me to adopt this workaround, then solve its shortcomings by adding even more workarounds. Use of realtime_trip_id or vehicle_id to unify multiple trips expanded from a single vehicle strikes me as such a layering of workarounds. Since boarding restrictions are in fact common, wouldn't a single-purpose new column (on new file if necessary) be justified? The new column/file would obviously have to be accompanied by an unambiguous explanation of its meaning. Pseudocode for trip planner implementations seems excessive to me (we don't require that for any other tricky features) but examples could of course be provided if people find the new data confusing. @LeoFrachet the comment about France was simply because I've lived in/around France for the last decade, and I heard trip planner developers there complain about it as an unusual local requirement. I also mentioned the Czech republic in that comment - I just wanted to make sure it was common outside these two places before creating special constructs, since French developers had previously implied to me it was a local oddity. @skinkie you stated:
I would say this is only true with respect to what Transmodel calls JourneyPatterns. It's specifically Trips that are not factored out (normalized) into generalized patterns of stops and inter-stop travel times. My understanding is that this is an accident of history, that initial creators of GTFS were just exporting from scheduling systems that schedule each trip independently (in the past I noticed a lack of repeating stop/travel time patterns in TriMet data). I think we should probably add JourneyPatterns to GTFS (which would bring it much closer to a minimal profile of Netex) but that's a different issue (<-- note @LeoFrachet). The rest of GTFS uses a more or less normalized relational model, and I think many consumers would make the assumption of one-to-one correspondence of trips to vehicles at any point in time. GTFS does require extensive transformations before routing can be performed (e.g. calendar/service days, and especially the expansion of exact-times frequencies into individual trips); again the idea that GTFS is directly usable without transformations applies primarily to the lack of JourneyPatterns. So I think it's more accurate to say: "GTFS currently doesn't require expanding JourneyPatterns into individual trips. Maybe it also shouldn't require expanding boarding restrictions into separate trips." The counterargument being: So, to refresh the idea of a new field or table: in all known cases, doesn't this feature prevent trips whose origin and destination are both within a certain zone? If so we just need a table that groups stop_times or stops together into zones, inside which local trips are not allowed. This is almost exactly the the Question: Are these zones mutually exclusive within any single trip? That is, are there overlapping zones? If not, then we don't even need a separate table. We just need a single new field that partitions the stop_times making up a trip into different zones within which local service is prohibited. This avoids the compound key and join to an additional table. |
|
Thanks @LeoFrachet for thinking working through the implications - I have read and commented on the full VehicleIds proposal at https://docs.google.com/document/d/1LazDOG2uSTJ_VzaTBlzk9Jjt88yeVBWLGXG2hsUxI6s/
Please read my comments on the VehicleIds proposal for some additional detail. In short, for all these cases including boarding restrictions, I'm in favor of clarifying that trips and vehicles are in one-to-one correspondence, and adding a few new columns that declare relationships between trips (and therefore vehicles at a given moment) or partition trips into zones. There may be advantages to making vehicles their own entities with their own table (handicap accessibility information, toilet facilities, wifi etc.) but such a table does not seem necessary to solve the above problems, and vehicle facility information like wifi availability could be distributed (denormalized) into the trips table. There is also a conceptual collision with the existing block_id that should be considered. |
|
On navitia we have a column with a zone id that is optional. I don't get the journey pattern thing, I'll try to read that more in depth at my return of vacation. |
The GTFS-VehicleIds doesn't speak about any additional table. It's about adding fields in
Adding a few columns declaring relationships between trips is the core of the GTFS-VehicleIds proposal. It offers to add 3 new fields in
I have the feeling you follow the train of thoughts that Josef & myself followed: (i) grouping stops by zones, (ii) realizing you cannot identify stop time using Regarding
What you are describing here is the "option A" in the GTFS-BoardingRestrictions proposal, at the bottom of the file, in the "Abandoned options" section. You'll see there described exactly what you're describing ("a single new field that partitions the stop_times"), with the counter example answering your question "are there overlapping zones?". Conclusion: I've added the pseudo code for expending the trips, I hope this answers the questions of how the |
|
Regarding backward compability, we could create new values for It would likely force consumer to either reject those rows are not parsable with existing tools, or to implement the new feature. |
|
Thanks for your explanation @LeoFrachet, it's necessary for me to reconstruct your thinking to have a solid opinion on the proposal.
I realize the current proposal does not yet create a materialized vehicles table. That was speculation about future uses. What I mean is that this proposal creates a new implicit entity class, a vehicle, which is not necessary to express any of the listed situations. Therefore I was questioning whether we need that vehicle entity class now, or will ever need it in the future for other features. If not, then instead of vehicle IDs you can simply use trip IDs, on the condition that trips are in one-to-one correspondence with vehicles at any given time.
I read the entire proposal and I realize this. I am just saying that you don't need to introduce the idea of vehicles as separate from trips to solve these problems. And as a general rule I'd favor the simpler solution instead of adding new entity classes.
Yes, I was just trying articulate my line of reasoning to confirm that it matched yours.
The document I was reading (GTFS-BoardingRestrictions proposal) did not make it clear to me that limitation_type was considered a rejected element. Thanks for striking out this section to make it clear, the presence of limitation_type was one of the main things I was questioning about this proposal.
Wow, I didn't catch that. They actually define two simultaneous, overlapping restriction zones where one is not a subset of the other. However there is no example in this section. It wasn't clear to me that in option A, the text "see Bileto’s example" was a back-reference to the beginning of the document. For future reference on the history of the spec, it is important to ensure that this reference is clear (using e.g. "example 1 at the beginning of the document").
Yes, now that the reasoning behind the proposal is clear I favor However I maintain that stop_time_limitations covers one prominent use case of vehicle_ids (unifying logical trips that all represent the same vehicle). So if stop_time_limitations is adopted, there is no need to represent a single vehicle with multiple trips, and vehicle IDs are no longer necessary to handle the listed use cases. Specifically: pulled_by can reference a trip_id instead of a vehicle_id.
Thanks. I think the algorithm needs some revisions - I added a comment on the doc. |
|
All good! A consensus seams to be slowing reached for GTFS-BoardingRestrictions option B, aka the use of a new file Therefore, let's get GTFS-VehicleIds out of the conversation from now (@abyrd: I agree with what you said about using It's mainly the name of the file which is still under discussion. We have:
I like board/alight, but "zone" sounds to geographical where it could here just be a set of [Message edited to replace the |
|
Maybe |
|
I'm expecting that the anglos in the room will say that it's not only about
boarding, but also about alighting...
umsteigen_limitations.txt would be more specific.
More seriously, yes, could be `boarding_limitations.txt`.
|
|
transfer_restrictions?
|
|
@LeoFrachet I think you meant stop_time_* rather than stop_name_* above. It's a valid point that they're not necessarily contiguous zones. As far as I know the only purpose of this is to describe restrictions on local travel, so @skinkie I don't see much of a connection to transfers, since this restricts the origins and destinations of rides. Your mention of transfers does raise one thing we should clarify about the proposal - are restriction zone IDs applied across journeys including transfers? This may be a problematic detail. If a rule doesn't allow you to ride bus A between stops belonging to zone 1, can you ride bus A outside zone 1, transfer to another bus B from the same operator, and ride back into zone 1 circumventing the rules? I assume we'd want to block this, which means zone IDs need to be valid across trips. |
|
I'm ok with (I wouldn't include local, the list that @jspetrak gave there is a few non-local cases). I've updated the proposal with Should we still name the field |
|
The question regarding limitations with multiple trips is a good one, I'll think about it and see how we can do it. |
|
I agree with where this proposal has come over the past few days.
In hindsight, what I really wanted was an unambiguous explanation of what the new fields mean and how they interact with each other, and pseudocode probably wasn't the best thing given the final spec will actually need it in words.
I'm in favour of I realise the proposal text isn't what will go into the spec, but I think it's still worth clarifying how stop_times.pickup_type and stop_times.drop_off_type will interact with travel_restrictions.txt. Specifically, if stop_times.drop_off_type == Generally speaking, travel_restrictions.txt only further restricts stop_times.txt. |
What about just
Actually, ideally the proposal will exactly define what goes into the spec before it is approved.
Yes, I think it's worth stating this in the proposal. Pickup / drop-off types in stop_times.txt do not override travel_restrictions; travel_restrictions do further restrict pickup / drop-off types. |
Updated
I've added the following sentence in the definition of the field
I agree. I removed the pseudo code for this reason. I think (/ hope) the new sentence in |
|
As a consumer, we can add this in Navitia (with the limitation that overlapping restrictions won't be available according to the actual internal data model). |
|
@LeoFrachet in principle OTP could support this as a consumer. However the implementation is non-trivial because OTP (like Raptor and some other algorithms) relies on grouping trips into JourneyPatterns with identical sequences of stops, so (as discussed above) we'll need a demonstrably correct way to expand trips with restrictions into a reasonably efficient set of patterns. The GTFS model code in OneBusAway and OTP itself will also need to be updated to include the new tables/fields. Someone would need to agree to write and maintain this code. If any organization that can allocate development resources to OTP needs this feature and can submit a working implementation we would certainly consider it for inclusion. |
|
I echo what @abyrd says about journey patterns. Some new stuff I'm working on for Esri has a similar problem. I've yet to come up with a reasonable way to deal with the existing pickup_type and drop_off_type fields, so I don't see us supporting additional, more complicated restrictions until a customer comes to us and specifically asks for it. |
barbeau
added
the
GTFS Schedule
|
Megabus an intercity coach operator in the UK will often have multiple stops within a town or city, however you can't buy tickets within any urban area. Currently we don't have a way to represent this. Creating multiple journeys with pickup and drop off doesn't really work, as you would end up with the number of urban areas the route goes through as the number of journeys to define it accurately. National Express (another intercity coach operator) has similar ticketing restrictions for some routes for some urban areas, thus more complex than the Megabus example. |
|
It certainly can be done automatically, which happens for FlixBus, speaking as producer. |
|
With regard of supporting this in OTP2: I discussed this with @abyrd and @gmellemstrand today. We can support this by emulating it using the internal OTP data model - without changing the Raptor algorithm. We currently do not have any plans to support it. |
|
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
added
the
Status: Stale
|
keep open |
github-actions
bot
removed
the
Status: Stale
|
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
added
the
Status: Stale
|
This issue has been closed due to inactivity. Issues can always be reopened after they have been closed. |
Hi everybody!
MobilityData received the request to improve the representation of the boarding & alighting restrictions in GTFS.
Issue
Some bus or train intercity agencies are allowed to sell tickets only for intercity trips, but not for intra-city trips. GTFS currently cannot represent such limitation.
Example of trip which cannot be described using pickup_type & drop_off_type:
Proposal
The proposal is to normalize an existing practice: the
stop_time_limitations.txtextension defined by Bileto (@jspetrak). Here is the proposal: bit.ly/gtfs-boarding-restrictions.Thoughts?
The text was updated successfully, but these errors were encountered: