This build on top of #2931
In OTP1 most client provided a way to page the results by looking at the trips returned and passing in something like the last-depature-time + 1 minute to the next request, to get trips to add to the already fetched results.
In OTP2 we want a better way to do this, witch utilize the known search-window, and return to the client the next/previous time to use in the next search.
We can also use this to do other optimization like reducing the number of trips based on some of the optimal trips outside the search window. This is a bit complicated to explain. But, if we get like 50 trips or more in a result ,we can throw away some of the trips at the last minute of the search - these will be included in the next search (next page) if they are pareto-optimal for that window. This solves another problem with the time-table; A trip at the end of the search-window is accepted, because it is the latest-departure, it only compete with trips from the same iteration (last-minute).
Design/Solution
A user want to find all trips leaving after 12:00. The user do a search and OTP return all optimal trips for the first 30 minutes. Then the user want to check if there is a better option after 12:30 and search again, but now from 12:30.
To achieve this the request need to have an optional searchWindow parameter, and the response will return the searchWindow used in the search. In addition OTP will calculate the next and previous departure/arrival time based on the arriveBy flag.
Version of OTP used (exact commit hash or JAR name)
dev-2.x
This build on top of #2931
In OTP1 most client provided a way to page the results by looking at the trips returned and passing in something like the
last-depature-time+ 1 minute to the next request, to get trips to add to the already fetched results.In OTP2 we want a better way to do this, witch utilize the known search-window, and return to the client the next/previous time to use in the next search.
We can also use this to do other optimization like reducing the number of trips based on some of the optimal trips outside the search window. This is a bit complicated to explain. But, if we get like 50 trips or more in a result ,we can throw away some of the trips at the last minute of the search - these will be included in the next search (next page) if they are pareto-optimal for that window. This solves another problem with the time-table; A trip at the end of the search-window is accepted, because it is the latest-departure, it only compete with trips from the same iteration (last-minute).
Design/Solution
A user want to find all trips leaving after 12:00. The user do a search and OTP return all optimal trips for the first 30 minutes. Then the user want to check if there is a better option after 12:30 and search again, but now from 12:30.
To achieve this the request need to have an optional
searchWindowparameter, and the response will return thesearchWindowused in the search. In addition OTP will calculate the next and previous departure/arrival time based on thearriveByflag.Version of OTP used (exact commit hash or JAR name)
dev-2.x