Overpass API/status

From OpenStreetMap Wiki
Jump to: navigation, search

Please report server failures here. Add the most recent entry first. (also set the correct row in Platform Status accordingly)

Note: This page is only meant for operational issues (server not available, areas outdated, ...). Please report software bugs on the Overpass API Github page

Invalid 2016-10-06

I'm sorry for the delayed reply. This is in the end an issue with the code.

Servers seem to have availability issues. See https://help.openstreetmap.org/questions/52384 for details.

Apparently, you want to use the old XAPI which is very limited and partially disabled, as stated in the servers status page at Platform Status.
Only the /xapi?map call is limited at this time. Mmd (talk) 10:24, 7 October 2016 (UTC)
XAPI is not the same as Overpass API, even when it is implemented on the same server.
XAPI will be translated on the fly into Overpass XML, it's simply a wrapper. Mmd (talk) 10:24, 7 October 2016 (UTC)
Most users do not need XAPI (which is old, poorly documented and basically unmaintained, and was stopped as well on the OSMF servers since long).
The reasons why XAPI has been discontinued on OSMF servers years ago entirely different (completely different implementation).
There's no problem with the normal API (as used with Overpass Turbo). — Verdy_p (talk) 20:28, 6 October 2016 (UTC)
If you translate the XAPI query into QL, you will experience exactly the same issues as before: http://overpass-turbo.eu/s/j9C . So the argument that this is XAPI related does not apply.
Note that Russian and German instances both have outdated precomputed "areas" (since long now, due to multiple severe issues on these servers that had corrupted their database multiple times).
Areas are entirely irrelevant to the problem at hand. Also, areas are nowadays updated very frequently on the German instance. The Wiki status is just outdated.
The French instance is much more stable and reliable and replies fast. But remember that precomputed areas still have a delay (which could be several days off as they are refreshed by some server-side bot running during low hours).
The French instance was offline for about 9 days in September due to DB rebuild and used a fallback during that time.
You also note that there's too many active long requests in the instance you test. Visibly a client is abusing its acceptable usage rights, or has internal bugs for communicating with the server and closing its sessions correctly to free up the resources or to correctly cancel its ongoing requests whose results are stored and cached waiting the retrieval of their results. — Verdy_p (talk) 20:38, 6 October 2016 (UTC)

As there's no limit on rambler instance, those queries all originate by Alexvanderlinden's app. /api/status will only shown your own query, never everyone else's queries.
@Alexvanderlinden: please follow up this discussion on the Overpass Dev Mailing list. Mmd (talk) 10:24, 7 October 2016 (UTC)
Where can I find this Overpass Mailing list? (and/or how to use it?) - Alexvanderlinden
Sorry, forgot to post the link: see this announcement for details. It's a bit forum like, you can also post your question via Browser. Mmd (talk) 18:43, 7 October 2016 (UTC)
This really looks like a performance regression in 0.7.53 with some compiler (settings). The query I mentioned above runs in 700ms on this instance, but takes more than 15s both on Rolands dev, the German and the French instance. New issue on Github was created. Mmd (talk) 19:07, 7 October 2016 (UTC)
I'm switching to "Overpass QL". See https://help.openstreetmap.org/questions/52384 for details. This seems to work properly (no availability issues so far). - Alexvanderlinden
Effectively, I doesn't really matter if you run your query as XAPI or Overpass XML or Overpass QL, as the XAPI will be translated to Overpass XML anyway before being executed. You're just lucky that there's not so much load on the server right now. In any case your query currently takes way too much time with 15s runtime, and if the load on the server increases again, you will run into exactly the same issues again. Just give it a try tomorrow at differnt times of the day and run your query a few times in a row. Mmd (talk) 20:48, 7 October 2016 (UTC)
@Mmd You are correct. I still face the same issues. Some more details at https://help.openstreetmap.org/questions/52384 . Is somebody trying to improve this situation or is this just to way it is now? Any tips or hints are welcome.
This issue can only be corrected via a code corretion, for which I have created an issue on Github. A pull request with a fix is already available, but Roland still needs to review the code, merge it and deploy it to the production server. Best is to contact Roland via email on progress. Mmd (talk) 07:57, 10 October 2016 (UTC)

Fixed 2016-09-29

overpass-api.de is currently about 9 hours behind the main database

Adavidson (talk)

Back to a 3 minute lag, so I guess it's fixed.

Adavidson (talk)

Fixed 2016-08-23

As I cannot rule out that something nasty has happened, I've re-installed the server and moved to Ubuntu 16.04 LTS. This has its own set of problems, but now I'm pretty confident that the system is clean. A basic service is now available again. Neither updates nor areas are enabled at the moment. I'll do that tomorrow.

The server still sees around 200 requests per second from thousands of different IP adresses without User Agent or Referrer. Could be both a careless app developer or an attack. But an attack would have most likely a much huger scale. As the defense that is cheapest for server resources, I have deleted the /api/xapi endpoint. This means that Apache can return a HTTP 404 on that without firing up a CGI session.

Some short remarks:

On page Platform Status is recommended "use http://tyrasd.github.io/overpass-turbo/ in the meantime as an alternative"
Just wanted to say, that NOW and the last hour (18:25, 21 August 2016 (UTC)) http://tyrasd.github.io/overpass-turbo/ seem's to have the same problems.
If I understand it correctly, the statement on the Platform Status related to Overpass Turbo (the user interface) rather than Overpass API. --Harg (talk) 20:17, 21 August 2016 (UTC)

There is a section for Overpass API and a separate section for Overpass Turbo. The alternative refers to Overpass Turbo, but both use the same backends. You can get around problems with the backend by changing it in "Settings > General > Server". --Roland

Update: Rambler is now completely back to normal operations. The main instance is back to normal operations but areas are still recreated.

I'm now sure that there is no malware on the server. I've just recreated the installation, now based on Ubuntu 16.04 instead of Ubuntu 14.04 before.

What has caused the sluggish reactions are the requests to the /api/xapi?map API call. I've made a statstic here: The important columns are the first (date), the seventh (number of requests) and the last (number of different IP addresses). Up to 2016-08-20, this call has seen some few requests per hour. Now we are at 300'000 to 500'000 requests per hour. For comparison: the total capacity of the server is rather 50'000 requests per second. As the outmost line of defense, I have removed the /api/xapi call such that Apache will get rid of these requests with a HTTP 404 not found.

I hope that the /api/xapi requests will go down in the next days if the source realizes that it won't get data. I have no idea what is the ultimate source. A local distribution of the addresses: First column is the name of the network, second column is the total amount of data (few because it's all HTTP 404), third column are number of requests, fourth column number of IP addresses.

I'll restore /api/xapi when this problematic access pattern has ceased.

Given the statistics, it is very likely to have been caused by a misconfiguration of an upstream routing , rather than by a single malicious app. However it is possible that some large commercial website featured an OSM map with some badly written scripts, relayed by some bad advertizing network (attempting to get some localized data about users in their browsers. It would be interesting to analyze the kind of XAPI requests performed: it could indicate which kind of geolocalized data these scripts were attempting to get, and could help locate the offending script or ads-network (or if it comes from some dating site). Apparently the data shows that this comes from both mobile and fixed DSL/cable/fiber networks. The distribution also shows a huge "success" in Czech Republic where an offending website woulds be best known. A single application seems unlikely, that's why I think about some advertizing network. Could it also be a non-official helper app made for Pokemon Go players ? — Verdy_p (talk) 12:13, 22 August 2016 (UTC)
If it was a badly coded website and/or advertising content, the requests would still have proper user-agent and referrer headers. Also, the mentioned requests from the Czech Republic (M-Soft_CZ) in the logs seem to be genuine ones (that still went through before the XAPI was closed), as they downloaded quite a large amount of data in relatively few requests from only two IP addresses. -- Tyr (talk) 12:46, 31 August 2016 (UTC)
https://overpass-api.de/achavi/ returns 404 Not Found, probably not re-installed yet on the new Ubuntu? Ikonor (talk) 18:12, 22 August 2016 (UTC)

Thank you for the reminder. I have now fixed this.

Areas are complete as well.

Another Update: The same "Request rejected" error is still happening when checking the fix for Issue #297, by running this query on the German, Russian, and French servers. Luckily the Swiss server is fine! -- Zstadler (talk) 20:36, 28 August 2016 (UTC)

That patch is not yet deployed, hence you need to wait a bit more for retesting. Swiss server contains data from Switzerland only(!), i.e. your query won't produce any meaningful result there, as there's no data to query in the first place. Mmd (talk) 17:16, 31 August 2016 (UTC)
Is there a way to know when a fix is deployed? Are fixed issues expected to be deployed on http://tyrasd.github.io/overpass-turbo?
Thanks for clarifying the scope of the Swiss server. I've updated its entry on the Platform Status page accordingly. -- Zstadler (talk) 08:00, 2 September 2016 (UTC)
The fix is deployed on the French instance (first public 0.7.53-instance with planet-wide scope). Mmd (talk) 10:50, 22 September 2016 (UTC)

See above 2016-08-21

I am getting either no response or an error message when executing a query from firefox developer browser -- example: http://overpass-api.de/api/interpreter?data=%5Bout:json%5D;(node%5B%22amenity%22=%22toilets%22%5D(51.64072811339469,-0.07122477654688271,51.68564387724827,0.0011869347500077093););out%20geom;out;

Response: Error: runtime error: open64: 0 Success /osm3s_v0.7.52_osm_base Dispatcher_Client::request_read_and_idx::timeout. Probably the server is overcrowded.

The same query works normally to http://api.openstreetmap.fr/oapi/interpreter/ (the result is empty, but that is correct for the specified area).

Earlier, I was getting a report in the console log that the site is not CORS enabled.

This is most likely a duplicate of the 2016-08-20 incident below. I'll report progress there.

See above 2016-08-21

Sorry for the late response. I can confirm that the server is responding much slower than normal.

I don't know much more so far. The Rambler instance has got a restart of the server. After this, it is required to restart operations manually. I've done this right now, hence the Rambler should be operational now.

The things that are happening on overpass-api.de are inconclusive. I do see that there is low load inside, but few requests from Apache are actually arriving. Test requests from outside don't get through to the CGI system. Hence, it is most likely somehow related to Apache or the network stack. Restarting Apache got operations back to normal for a few minutes, now it is again slow. I'll try a server restart next.

More details to the 2016-08-20 incident

The following error is received running this wiki example as well as any other query on overpass-turbo.eu:

An error occured during the execution of the overpass query!
Request rejected. (e.g. server not found, request blocked by browser addon, request redirected, internal server errors, etc.)
Error-Code: error (0)

-- Zstadler (talk) 15:31, 20 August 2016 (UTC)

This request is probably too large with the current server load (I tried your request, it works perfectly). My queries (returning about 10MB with complex selection) are working. — Verdy_p (talk) 15:48, 20 August 2016 (UTC)
This is just the first example from Overpass_turbo/Examples. I assume there was no issue with this example since it was created on 13 February 2013... -- Zstadler (talk) 18:15, 20 August 2016 (UTC)
I suggest you retry running your request from another browser, or usuing an "in-private" browser session: if it succeeds, you've got something wrong in your browser plugins. Try also by selecting another Overpass instance (from the preferences menu; for me all 3 instances are working). Try also rebooting your PC (if you have pending updates partially installed, in your browser, or antivirus, or networking components...), or your Internet router (if it runs out of available sessions/ports in its builtin NAT/firewall, or fails in its DNS queries). — Verdy_p (talk) 15:55, 20 August 2016 (UTC)
I've verified the issue with bare-bone Internet Explorer before reporting the issue. -- Zstadler (talk) 18:15, 20 August 2016 (UTC)
Same problem even for tiny requests; I assume it is a server-related issue.
The main instance seems to experience massive load on the Apache side, as even http://overpass-api.de/ is extremly slow to answer (if at all). Rambler instance is also down for most of the day, as the dispatcher doesn't seem to run (error message "Runtime error: open64: 2 No such file or directory /osm3s_v0.7.52_osm_base Dispatcher_Client::1 "). Recommendation: Try HTTPS instead or the French instance for the time being. Mmd (talk) 17:33, 20 August 2016 (UTC)
Yes, I noticed the French server is working fine. This report is about the the main server, which is the only server that has Attic data.
Note that HTTPS also returns an error, yet the error message is a bit more clear:
An error occured during the execution of the overpass query! This is what overpass API returned:
Error: runtime error: […] Probably the server is overcrowded.
-- Zstadler (talk) 18:15, 20 August 2016 (UTC)
I don't see any significant increase of execution time on Rambler even for my more complex requests. The request given in the example above replies correctly almost instantly on all 3 servers. Several days ago, there were still an ongoing massive load due to a bot reconstructing data after a bug, but this has been visibly fixed.
Anyway, most of the time I'm on the French or German instances (and I never need Attic data with Overpass, I use attic data only in JOSM for restoring some incorrectly deleted objects). For me, Overpass is for querying data as it is now, and there are QA tools to detect things that were recently broken (In most cases however it is rarely needed to restore data and corrections are evident (and we can look at history of objects as long as they are not deleted). I see little use for using Overpass with attic data (and we know that if you use them, the queries will be very underperforming, so you need very selective queries (by object id or in a small bounding box not larger than a few kilometers, or much smaller in dense cities). If possible post a link to the Overpass query (click on the "Sharing" option at top of screen, it opens a dialog with a short permalink to the query saved on the Overpass interface web server such as "http://overpass-turbo.eu/s/" followed by a very small opaque identifier made with a few lowercase/uppercase letters and/or digits). — Verdy_p (talk) 18:33, 20 August 2016 (UTC)
Correction: now I see the problem too on the Russian instance (only this one).
Something happened to the server at about 2AM on Saturday. Have a look at the Munin graphs. Adavidson (talk) 02:25, 21 August 2016 (UTC)
This did not happen on OSM servers (nothing visible at that time on its Munin stats on any one of the listed servers). Which Munin are you speaking about? Overpass API servers do not run on any OSM server but are hosted and administered by individual chapters, on their own platform, with their own colocation providers and bandwidth providers, their own domain names, and their own monitoring tools (not visible on the general Server status page). And is it really the same problem on the German and Russian instances running separately? — Verdy_p (talk) 02:57, 21 August 2016 (UTC)
The German instance was slow, now it is simply broken/down, with an error replied imemdiately. For now only the French instance runs (possibly the Swiss too for some requests, but it does not cover the full planet). — Verdy_p (talk) 03:20, 21 August 2016 (UTC)
Munin page for the overpass-api.de instance Adavidson (talk) 03:49, 21 August 2016 (UTC)
That Munin is not replying either (immediate error). There's definitely a problem on the web server or on its front firewall/router. — Verdy_p (talk) 11:39, 21 August 2016 (UTC)

Maintenance work 2016-08-14

To fix data damage caused by a software bug, the main instance and later on the Rambler instance will lag behind by some hours for some hours. The general availability is hopefully not affected. Work is scheduled to start at around 07h00 UTC --Roland

overpass-api.de is back to normal operations.
Rambler is also back to normal operations. --Roland

Invalid 2016-06-11

Clone mechanism on dev.overpass-api.de does not seem to work anymore. Clone script asks for .gz files, but only the uncompressed files are available for download.

The clone directory looks as it should look. Just in case, I've updated it right now. Could you please tell me which version you use to clone? --Roland
In the log files I noticed someone trying to download *.gz files for more than a week. There's a commit to remove gz based downloads, but that hasn't been merged into master yet - it's still in minor issue branch. I guess that person was using the master branch, where download_clone.sh is currently not working as advertised. Mmd (talk) 20:36, 16 June 2016 (UTC)

Done 2016-05-17

Server overpass.osm.rambler.ru does not respond (http/ping)

It's impossible for me to login and see what has happened as well. --Roland
Basic operations (interpreter for node, way, relation, areas) are back up again. --Roland

Invalid 2016-05-04

Errors when using the "changed" filter - only on overpass.osm.rambler.ru. Received

runtime error: open64: 2 No such file or directory /spool/roland/v0.7.52/db/relation_changelog.bin File_Blocks::File_Blocks::1

message when running this query on this server.

The rambler instance doesn't have attic information. "changed" is (as opposed to "newer") only available with the attic module.
Please consider updating the "attic data" column entry for rambler in the Overpass_API#Introduction table.
Also please consider rephrasing the error message.

Fixed 2016-04-28

The databases on all instances lags significantly behind. The reason are connectivity problems with the upstream server [planet.osm.org] for the diff files.

The planet.osm.org delivers again diffs and the updates have catched up.

Fixed 2016-04-18

Rambler Overpass API instance and Overpass API on openstreetmap.fr reject all the requests.

The rambler instance was up but has been spammed with useless requests from a poorly designed app, firing several identical requests at once and dozens of times per second. Unfortunately, the requests contain no useful user agent. Thus I cannot contact the developer. I've blocked this and similar requests now.
Meanwhile, the developer of the problematic app has contacted me and fixed the app.

Fixed 2016-04-13

sketch-line options are missing. style=padua and style=wuppertal are out of order.

Thank you for the notification. It should be fixed now.

Fixed 2016-04-13

Areas on overpass-api.de were last updated on 2016-03-30T00:26:01Z (it was expected that areas should be updated every 6-12 hours).

If this causes problems, try running your request instead over http://overpass.osm.rambler.ru/cgi/

I'm currently in the process of moving to a new piece of hardware, [1]. There areas will be reupdated once we are on the new server. I'm sorry for the break.

Done 2016-03-17

Areas on overpass-api.de were last updated 2016-02-11T09:13:02Z, that's about a month ago.

It has been turned off during the 2016-02-13 event. It's time to turn on area updates again.
Area updates have been turned on again.

Fixed 2016-03-15

Disk read errors on rambler.ru instance since 2016-03-12. It is probably the same problem as during 2015-11-12.

The server got a new cloned database, and is currently applying updates.

Done 2016-02-13

No updates on any instance since 2016-02-12 02:30.

It's again the problem that the servers have caught an invalid minute diff. The dev@ instance already is restarting with updates from the latest known good clone. The overpass-api.de instance will receive a rollback this night. -- drolbr

The rollback on the dev@ instance and the overpass-api.de instance has been completed. Both are back to normal operations. The rambler instance is still to do and will come back during the weekend, as well as areas on all machines. -- drolbr

Obsolete 2016-02-12

No more database updates on rambler.ru instance since 2016-01-20T18:00:02Z.

Please see above. Unfortunately, I have overlooked changes on this page because the wiki notification didn't work. -- drolbr

Obsolete 2016-02-12

Area update processes on overpass-api.de stopped again on Dec 18. Areas on rambler.ru were last updated on Nov 13.

This already causes some strange effects for some queries, reported e.g. here and here

Please see above. Unfortunately, I have overlooked changes on this page because the wiki notification didn't work. -- drolbr

Obsolete 2016-02-12

Area update process seems to have stopped on overpass-api.de at about 2015-11-16, 05:45 UTC. That happened towards the end of a 15480 seconds replication delay (upstream replication issue). Mmd (talk) 11:37, 17 November 2015 (UTC)

Please see above. Unfortunately, I have overlooked changes on this page because the wiki notification didn't work. -- drolbr

Obsolete 2016-02-12

Rambler instance no longer provides meta data for nodes:

... (Voluminous details removed)

Please see above. Unfortunately, I have overlooked changes on this page because the wiki notification didn't work. -- drolbr

Mmd (talk) 17:17, 12 November 2015 (UTC)

I haven't found an explanation immediately. But most likely, it is again the disk problem. I'll check tomorrow. -- drolbr
May be related: attic also used to work about 2 weeks ago on rambler, now I'm getting "remark": "runtime error: open64: 2 No such file or directory /spool/roland/v0.7.52/db/way_tags_global_attic.bin File_Blocks::File_Blocks::1"

Up again 2015-10-19

Update process on rambler instance seems to have stopped yesterday, more than 24 hours ago:

   "timestamp_osm_base": "2015-10-15T09:39:02Z",
   "timestamp_areas_base": "2015-10-15T09:39:02Z",
It looks like a disk failure on the server. To be sure I'm currently checking the disk.
The disk has shown not so few bad sectors. Now I'm cloning back the database from dev@ and hope that the Rambler instance will work afterwards.
Last hard disk issue on rambler was quite recently (see 2015-07-18 below). A hardware replacement may be really needed here to ensure longer term stability. Mmd (talk) 09:10, 23 October 2015 (UTC)
The instance has gone offline for unknown reason. I currently cannot login. -- Roland
The instance now has worked properly for several days. It is still unclear in what state the disk is. -- Roland

Fixed 2015-10-03

overpass-api.de and the Rambler instance have stopped applying updates. The reason is that a bogus version of the minute diff [2] before a reboot of the replication generation has been applied, and now the data is inconsistent.

I will reconstruct the database from a clone snapshot on dev.overpass-api.de with the now corrected minute diff in question. This may take some time. Until then, the public instances will suspend all updates.

The endpoints


are not affected. The server had received the correct copy of the minute diff.

The main instance is now back to normal operations. The rambler instance will get a database reset later on this afternoon.
The rambler instance is now also back to normal operations. Areas are yet to be recreated. The data transfer from dev.overpass-api.de has been far slower than expected.

Fixed 2015-09-16

On the main instance some bogus areas have appeared. The phenomenon cannot be reproduced on the other instances. To check whether it is a non-spurious problem, I've deleted the existing areas. The areas are currently being recreated. -- talk

The problem did not come back. It is most likely due to a bug in code transferred from the backend_cache branch. -- talk

Resolved 2015-08-25

The main instance seems to did not accept any requests since about midnight of August 25. All requests are rejected with the following runtime error: “Error: runtime error: open64: 0 Success /osm3s_v0.7.51_osm_base Dispatcher_Client::request_read_and_idx::timeout. Probably the server is overcrowded.”. See also the related current munin stats and this ticket on github.

Thank you for reporting the issue. In fact, the main instance has started to reject requests already since 2015-08-24 13:06 UTC. --rmo (talk) 16:09, 25 August 2015 (UTC)

Fixed 2015-07-18

The rambler instance reports a permanent "input/output error" for one file of the database. I haven't found what this means in detail but it might be a hardware problem.

The test requests still work, but the update process is on hold. Hence, arbitrary requests are likely to work, but no updates will be applied. The server may get rebooted at any time if necessary to investigate the I/O problem.

The rambler instance is now down for disk checking.
The rambler instance is back. Areas are still recreated.

Fixed 2015-04-30

Similar to the incident of 2015-02-05, the server overpass-api.de has received a bogus version of minutely diff file 1374687 (see this Github ticket for details). This has broken some elements.

I'm currently replaying a backup on the successor machine, next.overpass-api.de. That one should go live in a few days and then fix the issue.

Since about May 10th, the new server is on duty.

Announcement 2015-04-09

The clone feature of the overpass-api.de instance has been shut down permanently. Please use


as base URL instead. The clone process is resource consuming, and the dev server is better suited for a load peak.

Announcement 2015-03-30

The rambler instance will recieve larger disks in the next few days. This can mean a short downtime.

The server is back to normal operations.

Fixed 2015-03-16

Overpass-api.de gives 2 hours old data. See for example: http://overpass-turbo.eu/s/8di vs http://www.openstreetmap.org/way/319081796

or http://overpass-turbo.eu/s/6En vs https://www.openstreetmap.org/changeset/29515776

17:28 MEZ: works again
Thank you for reporting the issue. It was a full disk. I've organised a solution good enough for some days with softlinks.

Won't fix 2015-02-05

On overpass-api.de, OSM elements that have been changed between 2015-02-04 08:00 UTC and 2015-02-04 09:18 UTC and also between 2015-02-04 09:18 UTC and 2015-02-05 06:00 UTC will show the former version instead of the latter version. Elements that have been changed again since 2015-02-05 06:00 UTC will not be affected.

By contrast on overpass.osm.rambler.ru, all changes from between 2015-02-04 08:00 UTC and 2015-02-04 09:18 UTC are simply missing.

This is a trade-off after a problem with the replication process on the main DB: the Overpass servers have received a bogus changeset. On overpass-api.de, I've re-applied the corrected diff afterwards. This reduces the number of affected objects from 60'000 to about 1'000. On the Rambler instance, I will keep the diff untouched to have at least one working instance if the out-of-order diff turns out to have unexpected side effects.

The data problem is likely to be completely mitigated with new hardware in April.

Recovered 2014-11-04

the Overpass API instance on overpass-api.de will receive in a few hours a data rollback to 22nd Oct 2014. This means a shutdown for two to three hours. Then it will catch up from 22nd October to recent data. Please see [3] for further details. The server is now catching up from the database state of Oct 22nd.

Main and attic data should now work properly and up to date. Areas are also up again.

Fixed 2014-06-26 20:50:00 UTC

The Rambler instance had a database disk error after restart. The problem was not reproducible. I've used the opportunity to reset the database and to update the Rambler instance to Version 0.7.50, with meta data and areas, but without attic data.

Completed 2014-05-10 - According to munin osm db lag stats, overpass-api.de is no longer updated since Friday May 9 (+21hours) Couchmapper (talk) 12:23, 10 May 2014 (UTC)

Database replication seems to have kicked in again some minutes ago, changing state to yellow. Couchmapper (talk) 12:27, 10 May 2014 (UTC)
Overpass API seems to be back in normal operation, setting state to completed. Couchmapper (talk) 13:27, 10 May 2014 (UTC)

Fixed 2014-04-22

On the Rambler instance, the database outage from last Friday has screwed up the database. The overpass-api.de instance is not affected.

As the best possible immediate measure I will re-apply all changes since Friday to the database. This may take up to two days. In the mid-term, I will clear this anyway: On 2014-05-02, it is planned to install a new Overpass version on the Rambler instance.

The database has catched up, and there is currently no indication of bogus data anymore.

Done 2014-04-16

Planned downtime: To add as a capcity enhancement a SSD disk, the server overpass-api.de will be down Wednesday morning. Please use during this time the rambler instance. It will operate as usual and should have enough capacity for this time of the day.

The server is back to normal operation.

Solved 2014-04-04 03:30 UTC

The rambler instance has got a sudden reboot. I've checked that everything looks OK after reboot and restarted the service. -- drolbr

Solved 2014-03-28

The API on http://overpass.osm.rambler.ru/cgi/ is down since about 27-03-2014 9:55 UTC. --Tyr (talk) 16:24, 27 March 2014 (UTC)

I can confirm the issue. The server has just been rebooted. I'll investigate whether there are signs of hardware malfunction. If everything looks good, I hope the service is back tomorrow. -- 18h55 UTC
The server is catching up. No indications of a hardware failure so far. Areas aren't updated yet. -- 21h30 UTC
The area regeneration process has been started. -- 05h50 UTC

Invalid 2014-02-05 13h

The API on http://overpass.osm.rambler.ru/cgi/ is not cross-origin enabled anymore. calling from JS gives me "The request was redirected to a URL ('about:blank') which has a disallowed scheme for cross-origin requests."

I cannot reproduce the problem here. Could you please, if you are working from a browser, then try whether the browser can fetch data via Overpass Turbo and "Settings > General > Server" set to the ramber instance? This would clarify whether it is a problem with the connection or with the browser. --Roland
Sorry, thanks for the hint. My adblocker changed its configuration and blocked the JS call.

Solved 2013-12-28 08h55 UTC

Something ugly happened to the area database on overpass-api.de. To get out of the problem, the areas are cleanly regenerated. This means that no areas are available on overpass-api.de until afternoon.

Areas are now back and (almost) fully operational. The areas from relations 60189 (Russia), 80500 (Australia), and 2186646 (Antarctica) have been blacklisted to avoid the problem to reappear. These areas will again be processed once a new version has a better error protection and recovery.

Done 2013-12-12 18h35 UTC

The rambler instance has an almost full disk. Please be prepared that the area feature might be put off on this instance. The area feature will be always active on overpass-api.de (where disk space isn't short).

Solved 2013-06-14 04h50 UTC

The overpass-api.de instance is less reliable than usual. The rambler instance is not affected. This is due to an unexpected behaviour of /api/augmented_diff. It is probably related to both the load of /api/augmented_diff queries and the size of the current diff. A first workaround didn't work as expected. A second workaround actually worked or the bug conditions never appeared again. --Roland

Solved 2012-11-02 08h05 UTC

The rambler server shows at least two unrelated file errors on one of its database files. The reason is not obvious, so I decided to reload the database by a clone from overpass-api.de. I expect the server to be back on the evening of 1st November.

Solved 2012-09-17

http://www.overpass-api.de/api/xapi?*[@meta][railway=*][bbox=-73.5534668,41.9921602,-66.862793,47.4800885] gives me some random stuff in Ireland. Presumably it's due to the license change. --NE2 23:14, 11 July 2012 (BST)

Whatever. It's not like it will be useful for editing until the OSMF fixes diffs. Thank you, OSMF, for giving us this silliness. --NE2 01:51, 12 July 2012 (BST)
Yes, there are no minute diffs. Hence, the database is frozen at its state of 2012-07-11 14:14 UTC. On the other hand, the link above points rather to somewhere in Canada than to Ireland. -- Roland
The link is for railways in northern New England (the northeasternmost part of the U.S.). But it also gives some railways in Ireland. --NE2 10:32, 12 July 2012 (BST)
Thank you for the error report. The Osmosis accident yesterday left some artifacts in the database, in particular some ways that pretend to exist although they are deleted in the main database. I have now deleted these ways manually, so no bogus data can get visible outside Ireland. I don't have detected more bogus data, but that doesn't necessarily mean that there isn't more bogus data. The possibly in Ireland remaing wrong data will be swept off with the database reload at the end of the redaction process.
To explain what has happened: A couple of wrong diffs have been generated by Osmosis yesterday and have been applied to Overpass API. As there is no undo for applying a minute diff, I have continued to apply the corrected Osmosis diffs. Now, if data has been touched in the faulty diffs and then never since then in a corrected diff, it remains in the bogus state. -- Roland
I am still awaiting the license change with a subsequent complete reimport of data. The remaining artifacts did not cause any further harm, so I still deem it acceptable to wait for some more days. -- Roland

The first ODbL-planet has been imported and has replaced the database involved in the incident. -- Roland

Invalid 2012-09-04

The PT line diagram examples on the site http://www.overpass-api.de/public_transport.html do not work anymore.

Do you mean sketch-route?. This has been disabled since quite a long time because explicit OSM object ids in links may suggest that these ids were permanent. However, thank you for pointing me that there existed still a reference in the documentation. -- Roland

(Moved feature suggestions to the discussion page).

Invalid 2012-07-09 04:57 UTC

The main server does not return nodes as of around noon today. Running the following query: '<osm-script> <union> <query type="relation"> <has-kv k="type" v="route"/> <bbox-query s="27.6839" n="27.7299" w="85.2885" e="85.3368,"/> </query> <recurse type="relation-node"/> <recurse type="relation-way"/> <recurse type="way-node"/> </union> <print/> </osm-script>' used to return a whole bunch of <node> elements, and then <way>s and <relation>s. As of noon-ish UTC today, the <node>s are missing.

I do get nodes in the response (7 nodes), e.g. node 314964021. Could you please try again? -- Roland

Solved 2012-06-13 11:45 UTC

The main server returns outdated data (for XAPI queries only, see below), from at least three weeks ago. --NE2 17:17, 12 June 2012 (BST)

As a next step, I have set up a new, larger machine, with IP overpass-api.de will for the moment forward all XAPI requests but the map requests to that machine. Note that the database there is currently a month behind, but the server is catching up. After all, one month old data is still better than no data at all. I will raise the process limit there until that server has considerable load. So please expect to still see the message "server overcrowed", but I hope, this will more and more vanish with increasing capacity.
Overpass-QL queries, XML queries, and XAPI queries starting with "xapi?map?" work normally on overpass-api.de. -- Roland
In the meanwhile, the new server has fully catched up. I will in the next days move the domain overpass-api.de to the new server. -- Roland
Yes, back to normal. Thanks a lot. --NE2 17:18, 13 June 2012 (BST)

Solved 2012-06-15 08:51 UTC

Rambler always returns "Sorry - server overcrowded." This started happening sometime this morning.

I tried to move some load to the rambler instance, but it didn't work. Now everything should be back to normal operation. -- Roland
The rambler instance doesn't respond any more. The web server returns "502 Bad gateway" even on static pages, and I don't get on the server by ssh. I ask the administrator to restart the server. If it is a hardware issue, it would likely take much longer. -- Roland

Rambler is back to normal operation. It was in fact a network issue, not a hardware damage. -- Roland

Solved 2012-06-13 11:43 UTC

The XAPI compability layer got into a problem with overload. Currently, queries of the form "xapi?*" have been disabled on the overpass-api.de instance. All other request (including XAPI request for specific element types, like "xapi?node" and the map call "xapi?map") work without restrictions.

The rambler instance is not affected.

The backgroud for this decision is that a single application (the iOS computer game Geomon) has roughly 30-fold the server load. I'll find a solution with the application developers and then remove the restriction.

-- When do you expect to be back to normal? User:Christine

I think tomorrow, around 8:00 UTC -- Roland
I still have no feedback from the Geomon team. Thus, the restrictions on "xapi?*" will remain for indefinite time. Please use the rambler instance for XAPI queries. -- Roland
In the meanwhile, the Geomon team has answered. The load problem will be solved with the next app update on Tuesday. Please use the rambler instance for XAPI queries until then. -- Roland

The rambler instance itself has been lost due to unknown reasons. The issue itself is solved after redirecting XAPI calls to the new overpass-api.de server. -- Roland

Solved 2012-06-10 21:50 UTC

Filtering by existence of multiple keys doesn't seem to work, e.g. if you want all nodes that contain a tag with key "historic" and also have a "name":

out qt;

This returns an empty result set, but when you just query for

out qt;

you see that most of the nodes have a tag with key "name" and therefore should be returned by the first query. (That's just a simple example, I actually have a more complex query with onions that include e.g. "natural" where the filter could decrease traffic more than in this example.)

Thank you for reporting this. This was a bug introduced with a hotfix after release 0.6.98. I have fixed it now. -- Roland
Thank you for the quick fix and your great work here. -- User:H. G.

Solved 2012-05-30 08:46 UTC

Pretty sure something's not working properly. http://overpass.osm.rambler.ru/cgi/xapi?*[@meta][railway=*][bbox=-91.7248535,30.1166216,-88.0114746,35.0749649] should give the railways in Mississippi, but it's returning stuff from all over, as well as incomplete ways. --NE2 06:55, 29 May 2012 (BST)

Something is wrong with Rambler. It only returns data with today's date.

I don't yet know what goes wrong at the moment, but it is surely broken. Thank you for reporting this.
I'll save the logs to do forensics and then make a clean restart. This will take until tomorrow morning. -- Roland
The update process hit a very uncommon but devastating race condition. I restarted the server with a fresh database from this afternoon, but updates won't start before I have fixed that race condition tomorrow. -- Roland
The server is back to normal operation, only the areas feature will still need some hours to regenerate. -- Roland
Cheers. Thanks for your work, so I can resume mine :) --NE2 10:16, 30 May 2012 (BST)

Invalid 2012-05-12 18:00 UTC:

rambler is not working, returning "The requested URL /~roland/api/interpreter was not found on this server."

The correct URL is




-- Roland

Ah, then it seems all the forms on this page need to be updated to use the correct URL. Thanks for your wonderful service! -- Joshdoe 03:37, 11 May 2012 (BST)
Thank you for this hint. I have replaced the outdated documentation by a link to the current documentation. -- Roland

Solved 2012-03-20 04:35 UTC:

Request to hhttp://overpass-api.de/api/xapi_meta?*[name%3DTschechieche+Spezialit%C3%A4ten+-+Handel+%26+Vertrieb] via taginfo faild with:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <meta http-equiv="content-type" content="text/html; charset=utf-8" lang="en"/>
  <title>OSM3S Response</title>

<p>The data included in this document is from www.openstreetmap.org. It has there been collected by a large group of contributors. For individual attribution of each item please refer to http://www.openstreetmap.org/api/0.6/[node|way|relation]/#id/history </p>
<p><strong style="color:#FF0000">Error</strong>: line 4: parse error: not well-formed (invalid token) </p>

I can confirm this bug. It it due to improper treatment of ampersand charaters in the XAPI compability layer. I'll fix that during the day -- Roland
It is fixed since quite some time, but I forgot to update this status page.

Solved 2012-01-21 08:00 UTC: Broken area-queries again, but this time with different error messages. E.g. the query from section "Download an entire city" at overpass-api.de fails with "Error: line 4: static error: Unknown tag "area-query" in line 4.". If I try to use area-query inside <query type="node"> element, I'll get only Internal Server Error.

Thank you for reporting this. I can reproduce the error but I cannot do much before I'm back from vacancies next Saturday. I'm sorry. -- Roland
It was possible to fix the error with simple means. It was a typo in a refactored piece of source code. -- Roland

Invalid 2012 Jan 12 12:55 UTC: wrong parameter order in bbox

A All bbox queries are failing due to some sort of memory error. The same bbox queries were succeeding earlier in the day.
A Example:


<?xml version="1.0" encoding="UTF-8"?> <osm version="0.6" generator="Overpass API"> <note>The data included in this document is from www.openstreetmap.org. It has there been collected by a large group of contributors. For individual attribution of each item please refer to http://www.openstreetmap.org/api/0.6/[node|way|relation]/#id/history </note> <meta osm_base="2012-01-08T12\:17\:02Z"/> <remark> runtime error: Query run out of memory in "recurse" at line 7 using about 640 MB of RAM. </remark> </osm>

I assume that in the above query the second and third parameter are in wrong order. Note that the order is West, South, East, North.
selects 30 degress of longitude and latitude, including randomly two thirds of Europe.
selects a bounding box of meaningful size around Rome and works fine.
No other bbox shows an error.

Solved 2012 Jan 1 21:05: bogus meta elements

A mistake in the version update (forgotten --meta parameter to dispatcher on the command line) doomed the meta file indexes. The core data is not damaged and keeps going on.
A new planet import is in progress and expected to be complete on early Friday morning. Meanwhile, please use the Rambler server with base link
http://overpass.osm.rambler.ru/cgi/. It has not got the version update yet and serves meta data without any restrictions.
Update: The Friday morning import has also two other flaws:
  • I started the minute updates at the wrong date. All changes from 21 Dec are missing.
  • I accidently deleted the wrong file when trying to get space on the server's hard disk. Thus, there are no meta data for nodes for the moment.
I'm sorry for all that mess. I've done it too much in a hurry.
Note: The new version itself isn't buggy. The dificulties are human failure while fiddling to install without service interruption.
At sunday evening, the switch to the import succeeded. On Monday morning, the server also has catched up to the minutely diffs. This incident doesn't harm any more.

Solved 2011 Dec 28 20:00: area-queries appear to be broken - did not reappear.

They fail with 'Error: runtime error: open64: 0 /osm3s_v0.6.95_areas Dispatcher_Client::request_read_and_idx::timeout. Probably the server is overcrowded.' While everything else works.
This is fixed now. The measure was to restart the dispatcher, i.e. the internal serializer of queries. For an unknown reason it refused all reading requests before.
It seems the problem mentioned below is back (2011 Dec 17 11:00). It has been fixed once again by a dispatcher restart. But it looks like there is a not reproducable bug in the software.
With extended diagnostic capabilities also the self healing has been improved. It looks like this works as a remedy against the unknown bug. Neither diagnostic messages nor the bug did reappear for roughly a week.
The update is not yet rolled out on the Rambler server.

Solved 2011 Oct 25 23:50: Some ways, e.g. way #4732211 showed no history information.

The investigation is still going on. The bug doesn't appear on a freshly imported database on the rambler server. Thus, it is either a race condition or caused by a bad recovery after the power outage.
A contributing factor has been identifi