Dynamic windows per route for SIRI retrieval

[adiwaz]

Goal

Create a logic to dynamically define per route id the best combination of length and number of SIRI retrieval windows, and integrate this logic in the timed process after GTFS read and stats.

Background

Our SIRI retrieval method query the last stop of every route with default of 12-16 5-mins windows, in order to get GPS points of all currently driving busses in this route, and not only the closest 3 (as would happen with a basic query without windows).
However, for long or high-frequency routes more windows are required to capture all driving busses. In addition, for long and low-frequency routes it is sufficient to query with less but longer windows and by that reduce traffic load.
Therefore, a better solution is to create a process that dynamically determine the number of windows and their time-length for every route, depending on its route stats (generated from GTFS).

Sub-tasks

1. Define the exact input and output of this process, so it can easily fit into the existing Jenkins and SIRI retrieval proecesses.
2. Define the logic that dynamically determines windows number and length according to route stats from GTFS. Specifically, consider the fields of peak_num_trips, all_start_time and mean_trip_duration.
3. Implement the process logic (python/Java?)
4. Integrate and schedule in the existing framework.

@evyatark @cjer @AvivSela @OrBin Please add your input.

[evyatark]

see explanation of current mechanism in
https://github.com/hasadna/open-bus/blob/siri-retriever-dev/siri/siri_retriever/siri-0.1/README.md