Re: [OSM-talk] Overpass API: new version 0.6.93, now with meta data
[@newer=2011-08-01] restricts the data to only those data last edited after the given date. This is only possible in combination with another conditional. Why wasn't something like [@timestamp2011-08-01] used? -- Darafei Komяpa Praliaskouski OSM BY Team - http://openstreetmap.by/ xmpp:m...@komzpa.net mailto:m...@komzpa.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-ja] Fwd: [OSM-talk] Overpass API: new version 0.6.93, now with meta data
? Overpass API Overpass??OSM??(ID?)??? ? OSM3 project XAPI?ONLY?XML??API?? ??? XAPI??? Original Message Subject:[OSM-talk] Overpass API: new version 0.6.93, now with meta data Date: Tue, 30 Aug 2011 21:38:44 +0200 From: Roland Olbricht roland.olbri...@gmx.de Reply-To: t...@openstreetmap.org To: t...@openstreetmap.org Hello everybody, 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 moment. 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 before. Read more information on http://wiki.openstreetmap.org/wiki/Overpass_API 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 respectiveprint/ 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 compatibility layer: [@meta] 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. [@newer=2011-08-01] 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 ofprint/ 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 statement. newer than=2011-08-01/ 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. Cheers, Roland ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-talk] Overpass API: new version 0.6.93, now with meta data
Hello everybody, 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 moment. 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 before. Read more information on http://wiki.openstreetmap.org/wiki/Overpass_API 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 compatibility layer: [@meta] 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. [@newer=2011-08-01] 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 statement. newer than=2011-08-01/ 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. Cheers, Roland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
