pickup_drop_off_window always required for areas

[klement-MENTZ]

Hello everyone,

in the documentation it says start_pickup_drop_off_window and end_pickup_drop_off_window are

• Required if stop_times.stop_id refers to stop_areas.area_id or id from locations.geojson.

To my understanding, this would mean that departures from areas always require an interval.
However, there are indeed on-demand services that run between two areas with fixed departure times.
Here is an example for area relations with fixed departures: https://www.vor.at/fileadmin/CONTENT/Downloads/Folder/Anrufsammeltaxi_Folder/AST_Infoblatt_MOSTI.pdf
I do understand that in reality the vehicle will start picking up passenger from that departure time on, but so do the operators that design there timetables in such a way.

Can someone clarify if this indeed currently not intended in GTFS-Flex or if I may have simply misunderstood it?

Currently, it would probably have to be solved in such a way that in this case the time window is filled with identical start and end times.

Thank You!

[westontrillium]

I believe in the design it was assumed that you could not set a fixed departure time with a zone-based service because it would change depending on the location a user wants to be picked up (and because it is on-demand service that is being described wherein the rider negotiates time and location within temporal and spatial ranges). Any eventual fixed departure time would be generated once the user negotiates with the agency and a trip is booked.

A solution to representing the kind of service you referenced would be to distinguish between business rules and operational behavior when describing the service with Flex. For example, one could set the window to match the timeframe the service operates within de facto even though it only schedules pickups at specific intervals de jure. So for the "from" zone, if you have departure intervals at 05:35, 08:35, 10:35, and 13:35, set the window at 05:35-14:00[or a value representing when you can reasonably expect the last pickup for the "from" zone to take place]. This way, a trip planner can "capture" a users query and link them to this kind of service. You can then include in the message field a note about departures taking place at fixed times so the user is aware that the prospective itinerary they are presented with may differ from actual travel times.

[klement-MENTZ]

Thank you for the response.
I agree that the actual time will be provided by the booking system and that the journey planner can only give an estimated time as long as the vehicles availability and position are not known. But a journey planner wants to be as close as possible to the actual departure time, considering connections to public transport.
When you use the whole time window instead of fixed departure you will, e.g. in rural areas with only three departures a day, have really bad JP results.

My suggestion is to change the presence requirement for start_pickup_drop_off_window and end_pickup_drop_off_window from Conditionally Required to Conditionally Forbidden.
For example like this:

start_pickup_drop_off_window	Time	Conditionally Forbidden	Time that on-demand service becomes available in a GeoJSON location, stop area or stop. For timebands if stop_times.stop_id refers to stop_areas.area_id or id from locations.geojson.- Conditionally Forbidden if stop_times.arrival_time or stop_times.departure_time are defined.

This will allow to model fixed departure or arrival times and I don't see how it hurts the format.
What do you think?

[westontrillium]

I can't think of any issues this change would cause on the producer side, but I'd be curious to hear from a consumer or two (@timMillet? @leonardehrenfried)?

Also, as a side note, there would need to be some changes to some documentation MobilityData owns, such as the "is it Flex?" decision tree and the GTFS components spreadsheet should this change go into effect.

[leonardehrenfried]

I'm in two minds about this. On the one hand it's nonsensical to be claiming to be everywhere in a zone at an exact time. (You've discussed this.)

On the other hand, this is exactly what the operator wants to communicate.

As Weston pointed out, this raises a few questions about what is and isn't flex. As a consumer I would not rush to implement this, as it would make an already complicated implementation even more complex.

I would like to try to convince you that you can achieve a satisfactory approximation of the linked pdf schedule with the tools that the spec already gives:

You could model it as a separate trips where each zone has a short window. It would look like this:

• Village A: 8.35-8.40
• Village B: 9.00-9.05
• ...

And then a later trip would have the following times:

• Village A: 10.35-10.40
• Village B: 11.05-11.00
• ...
  This would mean that we don't need to make the spec more complex and get a result that is close to what the operator claims.

Would this work for you?

[klement-MENTZ]

We could work with it, but of course we want the best possible solution.
Another point I would like to make. In the data formats NeTEx (VDV462) and HRDF (Version 5.40.72) it is possible to map a service in this way. So if conformity with these formats is the goal, the change would be a step in the right direction.

[leonardehrenfried]

I don't believe that being in line with these standards is a goal of GTFS which is highly pragmatic and orders of magnitudes easier to produce and consume than, say, Netex. Otherwise, what's the point of having several standards?

Coming back to the topic, I wouldn't vote against this proposal (but probably abstain).

[klement-MENTZ]

Ok, what is the process to make a decision here?
My preference is to make the change to the standard. But no matter what the final decision is, I have something that I can communicate to users of our interface and something that (hopefully) won't change in the future.

[leonardehrenfried]

The entire Flex module is still in proposal stage so the process for getting something change is very informal.

However, getting this into the main GTFS spec is about to start (first videomeeting on Wednesday) and that is a relatively long process of feedback and voting.

If you care about GTFS Flex you should be part of that process. Get in touch with Elias Gino Cripotos from Mobility Data or join #gtfs-flex on the MD Slack.

[eliasmbd]

@leonardehrenfried @westontrillium Thank you for contributing to this issue!

@klement-MENTZ as Leonard mentioned we will be having our first meeting on GTFS-Flex this Wednesday. You are welcome to join us. The scope of the meeting is to discuss the adoption of the service discovery aspect of flex. This first increment would stabilize the extension and allow for more complex use cases. We will also bring up what the future holds for GTFS-Flex if this service discovery proposal is adopted.

Sign up for the meeting here.

[klement-MENTZ]

Thank you. Yes, I will join and am happy to contribute.

[klement-MENTZ]

Based on the discussions here and in #388, I am closing this issue.
It is a rare use case and there are ways to model them differently.