Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arrive by direct flex result filtered out because it is too short compared to transit #6046

Open
leonardehrenfried opened this issue Sep 5, 2024 · 2 comments · May be fixed by #6050
Open
Labels

Comments

@leonardehrenfried
Copy link
Member

@daniel-heppner-ibigroup has reported the following problem with a Seattle data set:

  • When flex direct (without transit) it is used as a mode, the expected result is returned.
  • When transit and flex egress is added to the modes, then the flex direct result appears, even though it's optimal as it's much shorted compared to the transit + flex option.

Investigation

This happens because the OutsideSearchWindowFilter computes an incorrect latestArrivalTime in this case:

public OutsideSearchWindowFilter(Instant earliestDepartureTime, Duration searchWindow) {
this.earliestDepartureTime = earliestDepartureTime;
this.latestDepartureTime = earliestDepartureTime.plus(searchWindow);
}

This is too simplistic, because the latest departure time is not actually earliestDepartureTime + searchWindow. The computation in RaptorSearchWindowCalculator also takes the minimum transit time into account:

public RaptorSearchWindowCalculator calculate() {
if (heuristicMinTransitTime == NOT_SET) {
throw new IllegalArgumentException("The minTravelTime is not set.");
}
if (!params.isSearchWindowSet()) {
searchWindowSeconds = calculateSearchWindow();
}
// TravelWindow is the time from the earliest-departure-time to the latest-arrival-time
int travelWindow = searchWindowSeconds + roundDownToNearestMinute(heuristicMinTransitTime);
if (!params.isEarliestDepartureTimeSet()) {
earliestDepartureTime = latestArrivalTime - travelWindow;
}
return this;
}

This then means that if you have a long minimum transit time and a short direct flex trip, it will be filtered out.

Example

  • arriveByTime: 11am
  • flex direct result goes from 10.50am to 11am
  • minTransitTime is 1 hour
  • search window is set or computed to be 1 hour
  • RaptorSearchWindowCalculator computes the earliestDepartureTime to be 9am
  • OutsideSearchWindowFilter takes the 9am and adds 1 hour, leading to a time window from 9am to 10am
  • the flex direct result is removed because it is outside of this window

Version of OTP used (exact commit hash or JAR name)

f2d8a1e

Data sets in use (links to GTFS and OSM PBF files)

https://github.com/leonardehrenfried/otp2-setup/ and use the seattle config.

Steps to reproduce the problem

  • git clone git@github.com:leonardehrenfried/otp2-setup.git
  • make build-seattle run-seattle
  • Run the following GraphiQL query: https://tinyurl.com/23fanlza
@leonardehrenfried
Copy link
Member Author

leonardehrenfried commented Sep 5, 2024

We talked about this in today's dev meeting and have come up with a way forward. I will be opening a draft PR which @daniel-heppner-ibigroup can test and Thomas and I will work on the details.

@leonardehrenfried leonardehrenfried changed the title Arrive by direct flex trip filtered out because it is too short compared to transit Arrive by direct flex result filtered out because it is too short compared to transit Sep 5, 2024
@t2gran
Copy link
Member

t2gran commented Sep 11, 2024

The search window do not apply to street-direct searches. I think that the direct flex also falls into this category. The direct ittineraries can be time-shifted. This is not always true for flex, but I think we do threat them like this anyway.

The direct search is only performed in the first page, not layer on.

The search-window filter should only be applied to transit(Raptor) results, because this is where the search-window is relevant. The minTravelTime is used to computer the search-window and is not relevant here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants