search

drolbr / Overpass-API

A database engine to query the OpenStreetMap data.
http://overpass-api.de
GNU Affero General Public License v3.0
716 stars 90 forks source link

is there a machine readable alternative to /api/status OR where is the content/logic of api/status defined? #619

Open jannefleischer opened 3 years ago

jannefleischer commented 3 years ago

I am trying to use osmnx with a custom overpass api configured with no slot management (via https://github.com/wiktorn/Overpass-API) - this results in an infinite loop because the /api/status won't give an easily machine readable response (see https://github.com/gboeing/osmnx/issues/697)

The issue is, that this: https://github.com/gboeing/osmnx/blob/main/osmnx/downloader.py#L248-L305 will parse this:

Connected as: 3232239617
Current time: 2021-04-27T07:56:26Z
Rate limit: 0
Currently running queries (pid, space limit, time limit, start time):

wrongly, because the slot information is missing.

So my question is, if the overpass-api/api/status can give a more easily processable machine readable format somehow? Or if not, can you point me to the right file in your code base, where the status page is generated (I couldn't find it... :/ ), so I can propose a better status parsing solution for non-default usecases? With looking on your code, I hope to learn which variants of /api/status can exist.

Thanks!

mmd-osm commented 3 years ago

@jannefleischer : original issue will be addressed in osmnx. I'd suggest to close this issue.

drolbr commented 3 years ago

The responsible source code is in src/overpass_api/dispatch/dispatcher_server.cc line 342 and following. As I understand from the linked issue the real problem here is that you might get the status from a different server than the query was sent to?

mmd-osm commented 3 years ago

As I understand from the linked issue the real problem here is that you might get the status from a different server than the query was sent to?

Yes exactly, /api/status may end up on another server, leading to inconsistent results. osmnx has fixed this now on the client side by making sure that interpreter and status always use the same server.