Raptor, unlike AStar(OTP1), MUST have a search-window. Raptor will search and find all optimal travels within that window. OTP1 is searching until it times-out or a speccified number of itineraries is found. The search-window is for a normal DEPART_AFTER search the time from the earliest-departure-time to the latest-departure-time. For a ARRIVE_BY search it is the time window from earliest-arrival-time to the latest-arrival-time. For a client/traveller it is inconvenient to supply 2 times for this (or a time and a window size).
The solution is to use some statistics to guess a good window size for the given search. If the search is short in a high frequency area we set the time-window short, and in the opposite case we set the window long. A short window would be down to 30 minute with maybe 3-10 different options/trips to choose from. While a long window could be 2 days.
Expected behavior
- Find at least one trip.
- Reasonable search time
- Pareto optimal results
Version of OTP used (exact commit hash or JAR name)
dev-2.x
Raptor, unlike AStar(OTP1), MUST have a
search-window. Raptor will search and find all optimal travels within that window. OTP1 is searching until it times-out or a speccified number of itineraries is found. Thesearch-windowis for a normal DEPART_AFTER search the time from theearliest-departure-timeto thelatest-departure-time. For a ARRIVE_BY search it is the time window fromearliest-arrival-timeto thelatest-arrival-time. For a client/traveller it is inconvenient to supply 2 times for this (or a time and a window size).The solution is to use some statistics to guess a good window size for the given search. If the search is short in a high frequency area we set the time-window short, and in the opposite case we set the window long. A short window would be down to 30 minute with maybe 3-10 different options/trips to choose from. While a long window could be 2 days.
Expected behavior
Version of OTP used (exact commit hash or JAR name)
dev-2.x