Handling Quota Limits

[mvglasow]

From README:

Datex2 and other APIs may have rate limits. The system must handle these limitations through caching and efficient data request strategies.

For one, Datex2 is just an exchange format. Each service offering Datex2 offers a different set of data (area and events covered), has a different update interval and – potentially – rate limits.

Non-Datex2 services also typically have update limits.

Therefore, I would suggest figuring out the update interval of each service and poll it with a frequency equal to the update interval – ideally, shortly after the update. That is the bare minimum to get everything (polling more often does not provide any benefit) and should not be an issue with most services (in the event that services have an usage limit which does not allow fetching one feed per update interval, we need to come up with something for that service).

For the solutions I have written, I have the update interval in the config for each backend (the config is shipped along with the product).

[TobiPeterG]

Hey, thank you for this information as well :)

This sounds like you already have an aggregator for traffic data already?

[mvglasow]

Sort of, see #4. RoadEagle acts as an aggregator, but as an Android app, not with a web API. My web aggregator project was still in its infancy when time constraints kicked in.