Rate limit reset on docker instance

Hi @adam @nils,

I was wondering what is the rate limit reset time frame for docker instances? I know I can increase limits but even with a big number, they are still limits. Does this limit reset every minute like on the api?

Even with waypoint limit of 99999999, I still get a query limit error for isochrones. This might be a server-server communication issue as I am running QGIS on our university server, but I want to make sure that’s the issue before tinkering with the server.

If you are running your own docker instance then there shouldn’t be any API limits as that is all handled via a separate system that the openrouteservice code itself knows nothing about…

The waypoint limit is the number of waypoints that can be used in a route (start, via and end points) and not something to do with the number of API requests. Can you post the limit error message?

Hi Adam,

Sorry, I don’t have docker logs as I took down the service. The limit error is -

But I think I solved it by increasing the isochrone parameters for distance and time.

But new error pops up and crashes QGIS completely. I checked a similar post Error 3099 Unable to build an isochrone and the graphs are built. Calculating isochrones using the ORS tools plugin for the same dataset works perfectly. But inside a script, looping this function seems to give me this error

21 Jul 13:07:39 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:39 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.
21 Jul 13:07:39 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:39 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.
21 Jul 13:07:40 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:40 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.
21 Jul 13:07:40 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:40 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.
21 Jul 13:07:41 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:41 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.
21 Jul 13:07:42 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:42 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.
21 Jul 13:07:44 ERROR [routing.RoutingProfile] - java.lang.IllegalStateException: Calculate snapped point before!
21 Jul 13:07:44 ERROR [errors.CommonResponseEntityExceptionHandler] - org.heigit.ors.exceptions.InternalServerException: Unable to build an isochrone map.

What could be causing this error? Do you think it is then a dataset issue? They are simple shapefiles of OSM points of interest.

OK, in the image you sent it is pointing to the main openrouteservice api rather than your local one, unless the qgis is logging incorrectly (You need to add a provider that points to your own instance).

For the script I am not sure. If it works normally (you can use something like Postman to send a single request) outside of the script, then it is likely something to do with the script itself as there shouldn’t be anything interacting inside of openrouteservice. Quite likely it could be that the latitude and longitude values are the wrong way around (you should pass it as x, y - so longitude, latitude).

The error messages that come from the isochrones are often quite generic and difficult to pin point the exact issue because of the complexity inside the isochrone generation processes…

Hi Adam,

I absolutely do not know how I missed that. Thank you for pointing that out.

But it is working now. Thank you for all your help.

No worries, it’s an easy mistake to make :slight_smile: