[DRT] Clarification on continuous pickup/dropoff value

[tzujenchanmbd]

This PR includes only clarifications for DRT:

• For DRT services indicated by start_pickup_drop_off_window/end_pickup_drop_off_window, allow value 1 for continuous_pickup/continuous_drop_off.

[westontrillium]

LGTM

[miklcct]

The use of positive integer is problematic here, because it implies that 0 is not a valid value, i.e. you can't specify an immediate booking.

[westontrillium]

@miklcct Positive integer is correct. 0 is not a valid value for these fields, because immediate booking is expressed with booking_type=0. All other booking types by definition require a non-zero amount of advance notice.

[miklcct]

also prior_notice_start_day and prior_notice_duration_max being forbidden for booking_type=0 is problematic, if you want to allow booking up to a certain number of days, or a certain amount of time before until the journey itself.

For example, if a service requires booking between 72 hours before but can be made right until the trip starts, booking_type will then be 0 but you still needs to make prior_notice_duration_max.

[tzujenchanmbd]

Deprecating the changes for "positive integer".

if a service requires booking between 72 hours before but can be made right until the trip starts

It does seem that this use case is not explicitly covered by the current spec. Currently, booking_type=2 is used for handling reservations made multiple days in advance, but it primarily applies to reservation rules based on an absolute time x days before the trip. This differs from the use case described here, which is based on x hours in advance.

@miklcct Do you currently have a real-world example of such a reservation rule? (A link would be nice!)

Perhaps we could modify the "same-day" description of booking_type=1? In that case, the described use case could be represented using booking_type=1 with prior_notice_duration_min=0, while booking_type=0 would continue to handle use cases limited to real-time booking only.

[westontrillium]

Come to think of it, I have encountered a few services that are pretty flexible with their booking requirements (i.e., "if we have availability, we can pick you up now or you can reserve a month in advance") which we've had to model more restrictively due to the limitations of each booking type.

I'd be OK with changing prior_notice_start_day to optional for booking_type=1 and conditionally allowing 0 values for prior_notice_duration_min if prior_notice_start_day or prior_notice_duration_max are defined. prior_notice_start_day and prior_notice_duration_min cannot coexist, however, so conditionally forbidden language will need to be modified for those fields.

We need to keep booking_type=0 as realtime only, otherwise, there would be no other way to describe services you can only book for rides right now.

[westontrillium]

If we want to move forward to these rule changes, it should probably exist as a separate PR.

[tzujenchanmbd]

We recently also discovered the following booking use case in Barcelona: https://www.teisa-bus.com/pdf/pdf3_transport_demanda_pdf45.pdf

• The service departs from the first stop at a fixed time and follows a fixed route with predetermined stop sequences, similar to a regular bus service.
• All fixed stops allow a 10-20 minute time window for boarding and alighting. Passengers must book in advance if they wish to use the service at a particular stop during that window.
• Bookings must be made at least 15 minutes before the departure time at the first stop, rather than 15 minutes before each stop's time window. This appears to align more with a booking_type=2 (absolute time) use case.

For this type of service, the most appropriate modeling under the current specification is likely be:
booking_type=2; prior_notice_last_day=0; prior_notice_last_time=[The time 15 minutes before the service departure].

As @miklcct mentioned, there may be cases where day=0 is needed.

Agree that clarifications on booking rules could be addressed in a separate PR. I am going to open voting soon.

[tzujenchanmbd]

I am opening a vote for this clarification. This clarification should not require extra implementation.

Voting ends on 2025-03-07 at 23:59:59 UTC.

[westontrillium]

+1 Trillium

[tzujenchanmbd]

Apologies just returned from business trips and vacation.

Since there were no objections in the previous vote, I will not make any changes and restart a new round of voting.

Voting ends on 2025-04-07 at 23:59:59 UTC.

@miklcct @gcamp @leonardehrenfried could you have a look at this clarification and vote?

[gcamp]

+1 Transit

[westontrillium]

+1 Trillium

[leonardehrenfried]

+1 OpenTripPlanner

[miklcct]

+1 Aubin

[tzujenchanmbd]

The vote passed on 2025-04-07 at 23:59:59 UTC.

4 votes in favour and no votes against.

Votes came from:
Transit (@jll01)
Trillium (@westontrillium)
OpenTripPlanner (@leonardehrenfried)
Aubin (@miklcct)

Thank you to everyone who participated!