WIP: Flex continuous stops implementation

[hannesj]

Summary

Currently OTP supports two types of flexible trips, unscheduled and scheduled deviated trips. this adds support for a third type, continuous stops. these trips operate like regular scheduled transit, but boarding and/or alighting is allowed on the way at least between a set of stops. This is modelled by having the stop index to be a floating point number, which represents the proportion of the length, which the vehicle has travelled between the stop pair the number is between.

Unit tests

TODO

Code style

Have you followed the suggested code style? Yes

Documentation

TODO

Changelog

Was a bullet point added to the changelog file with description and link to the linked issue?

[amenk]

What do you mean by this TODO? Does this mean it is currently generating a straight line between to regular stops and has still to be aligned with the shape ?

[hannesj]

Yes, it calculates a direct path to the following stop

[amenk]

sounds fine? Or do we need to add "_" + i to make it unique?

[hannesj]

The generated StopLocation is the area between the two stops, so it should not have the stop id of the preceding stop

[amenk]

Then we should use both IDs of both stops?

[amenk]

I had a look at the branch, while I managed to compile (with Java 11), my trips disappeared in that old OTP2 version

11:02:24.560 INFO (FlexTripsMapper.java:50) Create flex trips progress tracking complete. 9 done in 0s (1.800 pr second). 
11:02:24.560 INFO (FlexTripsMapper.java:51) Done creating flex trips. Created a total of 8 trips.
11:02:24.568 INFO (GenerateTripPatternsOperation.java:77) Added 8 frequency-based and 0 single-trip timetable entries.
11:02:24.575 ERROR (OtpTransitServiceImpl.java:130) OTP2 do not support GTFS Trip Frequencies. See https://github.com/opentripplanner/OpenTripPlanner/issues/3243.

I think the next step would be to merge the branch with dev-2.x, but there are tons of conflicts.

We are working with "informal" / "popular" transport (minibusses) and there it is quite crucial to be able to drop-off any time. While there are possible workarounds (keep using OTPv1 which seemingly supported this (?) or generate pseudo-stops during the export from OSM2GTFS), we really would prefer to move forward with proper GTFS files and OTPv2.

On the mailing list it looks like others are also interested in this feature.

While we realized today that we a probably not able to finish this on our own, we surely can help with testing and probably also fund parts of the development.

@hannesj are you (or anyone else) interested to finish this feature? Can you list / estimate the remaining work?

What is missing to it?

• merge with current dev-2.x
• tests
• aligning the intermediate stops on the shapes, do not use a straight line (?)
• anything else?

I am also reachable via email: alex at addismap dot com

[2martens]

We have lines with continuous drop off in the evening on parts of the line. These are regular lines and their usual stops are all called at. But if you have a destination between stops, you can get off between the stops. This is a feature we will need. I cannot yet say at what point we will have development resources for it but I hope we get to it within the year.

[amenk]

We have a similar use case and are still interested.
Unfortunatly we cannot develop this on our own, but we would be happy to fund (parts) of the development.
Currently we stick with OTPv1, which seems to support this already in a way, but this is not a good long-term solution.

[2martens]

I think the first thing to do is to find consensus on the actual functional goal of this PR. Next would be the actual technical implementation on how to achieve that goal.

Based on our real-world use cases, I would describe the goal in form of expected results. If I have a search from a station to a station, this PR should not affect that in any way. If the destination is a coordinate/street address/POI (aka anything where no trips stop), this PR comes into play:

Condition: destination lies close to a shape of a trip that allows continuous_drop_off between the stations at that point
Expected result: footpath from closest point of shape to destination rather than footpath from closest regular stop of that trip. Footpath would have to be accompanied with information on how to organize the drop off (e.g. coordinate with driver).

That is our requirement, nothing more. We don't have continuous_pick_up situations. Maybe pickup and drop off can be split if that makes technical implementation easier. Our current production route planning just leaves a footnote on the trip without any routing impact. So this would be an improvement and more visible to potential riders.

Now to a possible conceptual implementation (with no idea if that makes sense in OTP):

1. raptor calculates the normal trip
2. post-processing looks at last journey leg and if that trip supports continuous_drop_off
3. if yes, then a shorter footpath to the shape is searched via OSM
4. if a shorter footpath (as in walking minutes) can be found, the result will be amended

Effect for rider: they see that they can leave the trip early
Effect for raptor: none as it happens after route calculation

This approach would have some advantages but also some disadvantages. The plus points:

• no changes to raptor which would allow this feature to be sandboxed, also testing would be easier
• rider can get amended route search
• intended travel relations remain key to calculation, preventing all sorts of odd result changes that depend on individual search requests and distance to the shape

Downsides:

• travel time to exit point is unclear, one could multiply calculated travel time with the relative position of exit point along shape between the two stops but that could be misleading/wrong

Another approach could be to precalculate a number of possible exit points between the stops. This could be fixed or configurable. In that case, raptor could treat that exit point as a stop point like every other. The issue with the travel times remain, as these exit points won't have scheduled arrival/departure times.

• Are there other ideas for the conceptual approach?
• Are there other functional use cases/expectations?

Once we are clear on the conceptual approach, we could check if the already available code in the PR matches that approach and in what way it has to be changed.

[amenk]

Thanks @2martens

We try to use this for informal and semi formal transport in Africa (mini busses). You can normally drop everywhere but in many cases also hop-on everywhere, while there are more or less stations stations which we are mapping.

Our main goal is also a drop off anywhere between the last two stations for a shorter footpath.
Hop-on between the first two stations still would be interesting for the same reason, but might not always be possible, of course, if the vehicle is full. So not sure if this always should be considered in an itinerary.

What is probably not necessary is to include drop offs and hope on in the intermediate legs - I think this is what you mean, and might maybe improve implementation and routing performance?

---

Additionally I want to point out that this worked already in OTPv1 - I guess it was removed to improve overall performance or because the routing was re-implemented?

[t2gran]

This discussion should probably be moved into an issue. There are several possible steps forward and I can help with the design/strategy. We will archive this PR if there is no activity by 01.01.2024. I would also recommend asking about it this at https://app.gitter.im/#/room/#opentripplanner_OpenTripPlanner:gitter.im or calling in to the dev meetings.