limitations for searchWindow API query parameter

[aheld84]

Dear MOTIS community,

I came across an unexpected behavior in the /api/v2/plan endpoint: I made the same query over and over again, increasing the searchWindow parameter each time.

I would have expected that all results from a query with a smaller value of searchWindow are included in the response to a query with a higher value of searchWindow and to get more and more results as searchWindow increases as long as the input schedule still has data and MOTIS server is configured with a large enough lookahead time (timetable.num_days).

Instead, I noticed that the number of results flattens out or even decreases, loosing results found with smaller values. I'm using timetableView=true and arriveBy=false on a self-hosted MOTIS instance with version v2.0.65. Here is a plot illustrating the situation:

The x-axis corresponds to searchWindow in hours and the y-axis to the number of itineraries in the response. At first, everything looks as expected, but after about 82 hours, the graph doesn't look right any more. The GTFS feed has data for 30 days into the future and num_days is set to 365 in the config.

I'm not sure whether I missed something and I'm not using it the right way or if there are any known limitations to values of searchWindow or the maximum number of itineraries or if this might be a bug.

I can probably work around it by making multiple requests with smaller searchWindow and shifted time. But how do I know which value of searchWindow is small enough to not loose any itineraries?

Thanks a lot,
Alex

[traines-source]

Yes I've tracked this down to a bug in MOTIS, thanks for noticing! I'll prepare a fix.

[aheld84]

Thanks for the quick investigation!

[traines-source]

Fixed with release v2.0.82. Beware though that we have now introduced a new config.yaml parameter limits.plan_max_search_window_minutes which limits the size of the search window that can be requested. By default it's set to 4 days, and it can at most be increased to 21600 (15 days) due to datatype limits. Probably better to use 14 days in requests (1209600 secs) due to rounding to the nearest day. If you need even longer searchWindows, you would need to do multiple requests. Let me know if you notice any issues.

[aheld84]

Thanks for the fix. It works for me within the limitations you mentioned.