[OSM-talk] Overpass API: new version 0.6.93, now with meta data
roland.olbricht at gmx.de
Tue Aug 30 20:38:44 BST 2011
I proudly present the new version 0.6.93 of Overpass API.
Overpass API now also provides the OSM meta data (timestamp, version,
changeset id, user name, and user id). This allows to use the data directly in
e.g. JOSM, including re-upload. It is the most-requested feature at the
Other features are a hardening of the software against file errors. The
<print/> statement now allows an attribute "limit" to limit the size of the
response. And a reworked planet import should now work about faster than
Read more information on
For the next version, which should be 0.7, I'll enable bounding boxes also
directly for ways and relations. Furthermore, the scripting language will get
some clean-up around the query statement and a concise semantic suitable for
effective GET requests. I hope, I'll complete that version in September.
Some details about the meta data:
As expected, this is twice as much more data (65 GB instead of 35 GB) and
makes the server an order of magnitude slower. To mitigate the effects on
those that don't need meta data, the feature must be explicitly requested. In
OSM script, this is done via setting the respective <print/> statement to
mode="meta". In the XAPI compatibility layer, add the directive [@meta].
The meta data give rise to the following special keys inside the XAPI
lets the database include meta data (version, timestamp, changeset
id, user name and user id).
[@user=Roland Olbricht], [@uid=65282]
restricts the data to data last edited by the user. He or she can
be identified by name or by user id.
restricts the data to only those data last edited after the given
date. This is only possible in combination with another conditional.
The corresponding tags in the scripting language are:
<print mode="meta"/> instead of <print/>
for the print statements that shall print meta data.
<user name="Roland Olbricht"/>, <user uid="65282"/>
can be used as a standalone statement and as a sub-statement of a query
can only be used as sub-statement of a query statement.
The [@changeset] special key is not realized. I want to keep up the
possibility to restart at any time for a recent Planet.osm, and that
Planet.osm won't contain elements that have been deleted meanwhile. Even
worse, the same is true for an old version referred in the changeset if the
element has been changed since then. A so much crippled response isn't useful
any more. These problems do have also an impact on the user and newer queries,
but I estimate them to be still useful.
More information about the talk