Talk:Overpass API/Overpass QL
- The old posts can be found on Talk:Overpass API/OverpassQL
Attic data ("date")
Example: The relation of Lake Nasser with the ID 280282. The changeset for the relations state contained in the first ODbL planet file was opened on 2012-06-02T13:23:36Z and closed on 2012-06-02T13:25:49Z. So querying for the relation for 2012-06-02T13:23:00Z returns nothing while a query for 2012-06-02T13:26:00Z returns the relation for this date. (Why a query for 2012-06-02T13:23:40Z doesn't work but for 2012-06-02T13:24:36Z does although at both times the change was not complete and what the query will return a more knowledgeable person may explain.) Malenki (talk)
- A changeset is not a "db transaction", where updates become only visible to the rest of the world, once you close it. In fact, any change you upload will be become immediately visible for the rest of the world and you can still add further changes later on to the same changeset! For Overpass API, only the object timestamp is relevant. The changeset open/close timestamps can be ignored for the purpose of finding out, if an object is returned or not. Mmd (talk) 17:52, 16 February 2015 (UTC)
If your query asks for an object in a state prior to what this planet file contains the API will return nothing.
- It would return the state contained in the first planet. Due to a DB inconsistency, overpass-api.de will indeed return nothing at this time, but as soon as the DB is rebuilt, you will get the state as in the first planet again (tested on my local instance). Mmd (talk) 18:36, 16 February 2015 (UTC)
Key/value matches regular expression (~"key regex"~"value regex")
Is it possible to simplify the syntax for filters using regexps for keys, but only equality for the value ?
A filter such as:
could be more simply written as
without having to escape some characters in the value and adding the extra "ˆ" and "$" bounds. I think that Overpass could perform itself this transform to the equivalent regexp.
Also, there should exist a way to query names by language (using a simpler mechanism, comparable to the lang() selector in CSS, i.e. using BCP47 language code resolution rules). The query above would become:
Or even more simply (if we don't care about "alt_ame", "old_name", "loc_name" and so on that this simpler form will not match):
And Overpass would transform the key regexp to match the ":languagecode" key suffix.
Still Overpass will infer the regexp, and there is still no support for excluding elements that match the specified name. Effectively the "!=" comparator is still not supported but could be supported using an internally generated difference of two sets, or an union of queries for each key value, depending on statistics:
When only one or or a few selective keys are matching, using an union may be a lot faster than using a difference between two large sets; it will be always faster if the input set has only one key matching the key regexp, or even no key at all in which case the output set will imediately be empty : the Overpass query engine can easily generate for each input set an index of all keys that are effectively used in it, possibly even with a counter for each one in order to evaluate some selectivity independantly of their values).
- Please read this Github ticket on regular expression support. Some of the points you're proposing are already mentioned there but got postponed. There's no more recent status on this, it simply hasn't been implemented due to other priorities/lack of time and/or resources, etc. I would suggest to create additional Github tickets for everything which is not covered in that ticket. To be honest, the :lang("en") looks like a very special case and is not very likely to be adopted at all. Just give it a try on Github. Mmd (talk) 18:14, 14 June 2015 (UTC)
- The lang() feature is very documented for use in XML, CSS, and very convenient for localisation (this includes performing Overpass QL to return data exposed to users on the map or hen clicking on a marker to sho details, ithout having long list of less relevant languages for translations); it handles correct fallbacks using BCP 47 resolution rules, not having to build complex regexps for them, and in case of multiple matches, it uses the most specific one (it acts just like a max() aggregator to return a single value matching the maximum specificity of the selector). And it reduces a lot the volume of data returned and loaded from the net, to be parsed by the client in a more memory-limited environment such as 32-bit browsers or smartphones. It saves also storage resources on the server for the temporary results that can be discarded much faster as the data ill be loaded by clients also faster. — Verdy_p (talk) 12:57, 5 March 2017 (UTC)
There is a link to http://permalink.gmane.org/gmane.comp.gis.openstreetmap.overpass/237 about memory usage. Unfortunatelly the link (Gmane) is broken. Do anybody knows another place to read it? --naoliv (talk) 10:50, 31 January 2017 (UTC)
- http://gis.19327.n8.nabble.com/Overpass-API-Development-f5839267.html, http://listes.openstreetmap.fr/wws/arc/overpass Mmd (talk) 12:51, 31 January 2017 (UTC)
- Unfortunately, the links above are pointing to the full archive. As a result, If you experience error messages like "runtime error: Query run out of memory using about 2048 MB of RAM.", you don't know what to do. If there is a link to the specific thread, I would gladly include a summary here. Zstadler (talk) 06:19, 24 March 2017 (UTC)