Let's say I want to find all nodes with 'amenity' tag in city Opole in Poland. I think something like this, but obviously it's not working:

relation["boundary"="administrative"]["name"="Opole"];
way(r);
node(w)->.nodes;
node["amenity"](poly.nodes);
out;

Overpass Turbo link.

Or maybe there is a simple way to do this?

Hello Roland,

Chrome's profiling tools suggested to enable compression for application/osm3s+xml, as its contents seem to be highly compressable. This might be useful to reduce latency/response times for users with limited bandwidth:

"Compressing the following resources with gzip could reduce their transfer size by about two thirds
interpreter could save ~39.46KB
interpreter could save ~68.83KB
interpreter could save ~73.55KB
...
"
I assume this could be done via a configuration change on the Apache server. Do you think this recommendation makes sense?

Best regards,
mmd

Some regular expressions with unicode characters don't work as expected:

node["contact:email"~"[öÖ]"];out;

This returns also nodes where conctact:email doesn't have an ö, but only other accented or umlaut characters (e.g. "bibliothè[email protected]" or "info@rügen-surfhostel.de").

Interestingly, the regex "(ö|Ö)" works just fine.

Hi,

I'm getting a runtime error issuing the following request:

curl -sSf "http:///api/api/interpreter?data=(node(-25.52,-49.35,-25.38,-49.16);%3C;);out;"

Immediately after the request I'm getting the error message, so it is not really a timeout.

The log file is like this:

2013-08-20 10:32:51 [640] request_read_and_idx() start
2013-08-20 10:32:51 [21456] waited idle for 142 cycles.
2013-08-20 10:32:51 [21456] request_read_and_idx of process 640 timeout 180 space 536870912.
2013-08-20 10:32:51 [640] request_read_and_idx() end
2013-08-20 10:32:51 [640] read_idx_finished() start
2013-08-20 10:32:51 [21456] waited idle for 2 cycles.
2013-08-20 10:32:51 [21456] read_idx_finished 640.
2013-08-20 10:32:51 [640] read_idx_finished() end
2013-08-20 10:32:51 640;out;
2013-08-20 10:32:51 [21456] waited idle for 2 cycles.
2013-08-20 10:32:51 [21456] read_finished of process 640.

The same request querying overpass-api.de is working fine.
However, the following request is failing with the same error message:
curl -sSf "http://overpass-api.de/api/interpreter?data=(node(53.05,7.97,53.80,6.90);%3C;);out;"

I can give further infos or logfiles when needed to track this down.
If it is an memory limitation, where can I change the setting? I'm running version 0.7.4 with ubuntu linux, 32GB RAM and 8 cpu

Thanks ind advance for any pointers..

I'd like to extract information about areas inside areas (e.g. to get information about regions in country). I am trying to run something like this:

<query type="area">
  <area-query ref="3600049715"/>
  <has-kv k="admin_level" v="4"/>
</query>
<print/> 

And it returns all areas (not limited to specified region). More or less the same query (but about nodes):

<query type="node">
  <area-query ref="3600049715"/>
  <has-kv k="shop" v="kiosk"/>
</query>

works fine. Is there a problem with API or I am doing something wrong?

Got a function mismatch

/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -std=c++0x --verbose -save-temps -MT make_area.lo -MD -MP -MF .deps/make_area.Tpo -c -o make_area.lo test -f '../overpass_api/statements/make_area.cc' || echo './'../overpass_api/statements/make_area.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -std=c++0x --verbose -save-temps -MT make_area.lo -MD -MP -MF .deps/make_area.Tpo -c ../overpass_api/statements/make_area.cc
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.6.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-std=c++0x' '-v' '-save-temps' '-MT' 'make_area.lo' '-MD' '-MP' '-MF' '.deps/make_area.Tpo' '-c' '-shared-libgcc' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-linux-gnu/4.6/cc1plus -E -quiet -v -I . -I .. -imultilib . -imultiarch i386-linux-gnu -MD make_area.d -MF .deps/make_area.Tpo -MP -MT make_area.lo -D_GNU_SOURCE -D HAVE_CONFIG_H ../overpass_api/statements/make_area.cc -mtune=generic -march=i686 -std=c++0x -fpch-preprocess -fstack-protector -o make_area.ii
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.6/../../../../i686-linux-gnu/include"

include "..." search starts here:

include <...> search starts here:

.
..
/usr/include/c++/4.6
/usr/include/c++/4.6/i686-linux-gnu/.
/usr/include/c++/4.6/backward
/usr/lib/gcc/i686-linux-gnu/4.6/include
/usr/local/include
/usr/lib/gcc/i686-linux-gnu/4.6/include-fixed
/usr/include/i386-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-std=c++0x' '-v' '-save-temps' '-MT' 'make_area.lo' '-MD' '-MP' '-MF' '.deps/make_area.Tpo' '-c' '-shared-libgcc' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-linux-gnu/4.6/cc1plus -fpreprocessed make_area.ii -quiet -dumpbase make_area.cc -mtune=generic -march=i686 -auxbase make_area -std=c++0x -version -fstack-protector -o make_area.s
GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2ed62271b86e2b75137544459bab1a81
../overpass_api/statements/make_area.cc: In static member function 'static std::pair<unsigned int, Uint32_Index> Make_Area_Statement::detect_pivot(const Set&)':
../overpass_api/statements/make_area.cc:113:64: error: no matching function for call to 'make_pair(uint32&, Uint32_Index&)'
../overpass_api/statements/make_area.cc:113:64: note: candidate is:
/usr/include/c++/4.6/bits/stl_pair.h:262:5: note: template<class _T1, class _T2> std::pair<typename std::__decay_and_strip<_T1>::__type, typename std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _T2&&)
make[2]: *** [make_area.lo] Error 1
make[2]: Leaving directory /home/mdupont/experiments/Overpass-API/src/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/mdupont/experiments/Overpass-API/src'
make: *** [all] Error 2

An incorrect query like

http://www.overpass-api.de/api/xapi?map?bbox=-360,61.60639637138627,202.5,89.7860070747368

Returns an error page which is sent with a 200 OK status code, which makes it hard to easily decipher between error responses and success responses. Ideally bad requests should trigger a HTTP 400 bad request response.

There is no Access-Control-Allow-Origin header for the kill_my_queries api call. It would be handy to call this from a web application in order to properly abort a query, woulnd't it?

Also, Overpass on rambler.ru seems to print out the Access-Conrol-Allow-Origin header twice, which is bugging (at least some) browsers.

The public transport tagging schema states that the "network" and "ref" tags are optional for a 'route' relation when there is a corresponding "route_master" relation. I really like this because the data is kept in a single place and it would be nice if the public transport line diagram would support this. Right now, the query built in 'src/cgi-bin/draw-line' only searches for "route"s, I tried to modify it to also take "route_master" into account and came up with this:

(
  (
    relation
      ["type"="route_master"]
      ["network"="$NETWORK"]
      ["ref"="$REF"]->.master;
    rel(r.master);
  );
  relation
    ["network"="$NETWORK"]
    ["ref"="$REF"];
);
(
  ._;
  node(r)->.__;
  way(r);
  node(w);
);
out body;

This works like before with the line "VRR"/"625" 1, but also works for "Verkehrsverbund Vorarlberg"/"90" 2, a line where the "route" relations don't have the "network" tag.

One little thing bothers me: When a "route_master" is present, it is also included into the output of the query. That's probably not a big problem, but I'm curious why this is the case (I use the ".master" variable to store the master relations, why do they show up in the output?). I also tried to change the query like this to filter out the master relations:

(
  (
    relation
      ["type"="route_master"]
      ["network"="$NETWORK"]
      ["ref"="$REF"]->.master;
    rel(r.master);
  );
  relation
    ["network"="$NETWORK"]
    ["ref"="$REF"];
);
rel(r._)
  ["type"="route"];
(
  ._;
  node(r)->.__;
  way(r);
  node(w);
);
out body;

This yields the desired output for "Verkehrsverbund Vorarlberg"/"90" 3 , but returns an empty output when looking for "VRR"/"625" 4. Very strange (at least for me).

Could you please modify the line diagram to also search for "route_master"s, and explain to me why the master relations are in the output and why the second query is wrong?

Conditional restrictions and similar constructs create a plethora of different tagging alternatives which are quite difficult to catch via normal Overpass API calls.

Example: http://overpass-turbo.eu/s/1jl

I'd appreciate a way to specifiy all these alternatives via a compact regex expression instead of an ever growing (and never really complete) list.

Is that technically feasible with today's data model?

Best,
mmd

When using the overpass API with CORS, the browser makes an OPTIONS request, and then a GET request to overpass. Currently overpass serves a full response to OPTIONS requests, so each $.ajax call is double bandwidth and time.

g++ -DHAVE_CONFIG_H -I. -I.. -std=c++0x --verbose -save-temps -g3 -Wall -O0 -MT overpass.lo -MD -MP -MF .deps/overpass.Tpo -c overpass.cc >/dev/null 2>&1
mv -f .deps/overpass.Tpo .deps/overpass.Plo
/bin/sh ../libtool --tag=CXX --mode=link g++ -std=c++0x --verbose -save-temps -g3 -Wall -O0 -o liboverpass-0.1.la -rpath /usr/local/lib expat_justparse_interface.lo settings.lo user_interface.lo cgi-helper.lo output.lo web_output.lo statement.lo area_query.lo around.lo bbox_query.lo coord_query.lo foreach.lo id_query.lo item.lo make_area.lo newer.lo osm_script.lo print.lo query.lo recurse.lo union.lo user.lo print_target.lo collect_members.lo scripting_core.lo map_ql_parser.lo statement_dump.lo map_ql_input.lo resource_manager.lo dispatcher.lo overpass.lo -lrt -lexpat
g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbeginS.o .libs/expat_justparse_interface.o .libs/settings.o .libs/user_interface.o .libs/cgi-helper.o .libs/output.o .libs/web_output.o .libs/statement.o .libs/area_query.o .libs/around.o .libs/bbox_query.o .libs/coord_query.o .libs/foreach.o .libs/id_query.o .libs/item.o .libs/make_area.o .libs/newer.o .libs/osm_script.o .libs/print.o .libs/query.o .libs/recurse.o .libs/union.o .libs/user.o .libs/print_target.o .libs/collect_members.o .libs/scripting_core.o .libs/map_ql_parser.o .libs/statement_dump.o .libs/map_ql_input.o .libs/resource_manager.o .libs/dispatcher.o .libs/overpass.o -lrt /usr/lib/libexpat.so -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o -Wl,-soname -Wl,liboverpass-0.1.so.0 -o .libs/liboverpass-0.1.so.0.0.0
/usr/bin/ld: .libs/expat_justparse_interface.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
.libs/expat_justparse_interface.o: could not read symbols: Bad value

Just found this strange bug. This query returns invalid JSON (a superfluous comma in elements array):

<osm-script output="json">
  <id-query type="node" ref="6666"/><!-- this node does not exist -->
  <print mode="body"/>
  <id-query type="node" ref="666"/><!-- this node does exist -->
  <print mode="meta"/>
</osm-script>

Apparently, this bug only occurs when the first result set is empty and the output modes are different from each other.

Whil I'm Implementing a table view for the overpass-ide (overpass-turbo) someone suggested not to show elements without tags, as these would not be interesting for the user.
IMHO it's slightly different: Objects returned by overpass (only) due to recurse statements are likely to be not of interest.
But it's not possible to identify these objects without reworking the query again.

Therefore a QL command to add custom tags to a data set would be great.
It would e.g. allow to

• select stuff
• add the tag "_self_selected"="true"
• recurse down

stuff could contain nodes and ways.
the result would contain nodes from stuff as well as nodes from the recursion, but only nodes from stuff would contain the _self_selected-Tag.

Hello Roland

We already talked about this: I'd appreciate to see additional set operations along the already existing union.

Example: I'd like to find all cinemas that are not reachable by bus: To do this I would search for the set of all cinemas and remove the set of all cinemas which are closer to the next bus stop than 500m.

There is a list of different set operations at https://de.wikipedia.org/wiki/Mengenoperationen#Mengenoperationen. I assume that it will be possible to implement all set operations by implementing a "set subtraction" that can be freely combined with unions:

Example:
Intersection (implemented with union and differences): (A V B) - (A - B) - (B - A)

Additional commands for intersection and symmetrical difference would be optional but may be a bit more user-friendly.

Edit: I would have liked to label this as "enhancement" but was unable to do so.

BBOX="-177,-44.5,-175.5,-43.5"
XAPI_URL="http://www.overpass-api.de/api/xapi"
wget -O chatham_hedges_and_fences.osm \
 "$XAPI_URL?way[bbox=$BBOX][LINZ:source_version=V16][barrier=hedge|fence]"

but it doesn't work :( for some reason it doesn't like the OR in [barrier=hedge|fence].
[barrier=*] or either value individually works as expected.

the result is a mostly empty file, with just the <osm ....> and </osm> in it, but nothing between them.

the sample on the help page works ok though:
http://wiki.openstreetmap.org/wiki/OSM3S#XAPI_Compatibility_Layer

wget -O test.osm \
  "$XAPI_URL?node[bbox=7.1,51.2,7.2,51.3][highway=bus_stop|traffic_signals]"

?? not sure what I could be doing wrong, so guess it's a bug ??

thanks,
Hamish

Hello,

first of all: thanks for all your work on Overpass! That's really useful.

I'm reporting a bug against draw-line: it seems like it's not working. Compare:

http://overpass-api.de/api/draw-line?network=Urbano+Mazara&ref=2&scale=10.0&pivot-lon=&font-size=12.0

with:

http://overpass-api.de/api/sketch-line?network=Urbano+Mazara&ref=2

Clearly the data is there, but seems like Overpass can't process draw-line.

I cloned the repository, and saw that, after the data is requested, draw_line_svg is being called -- but I can't find the source of that binary! Maybe the implementation is not yet complete?

Thanks,
David

Adding charset=utf-8 to the json Content-Type header will help browsers properly display non-ascii data such as this example http://overpass.osm.rambler.ru/cgi/interpreter?data=[out:json];node[name%3DGielgen][place%3Dsuburb]%3Bout%20meta%3B (On my install of Firefox 15, it decides that the data is encoded in latin1, resulting in mojibake)

I believe this is on line 193 of src/overpass_api/frontend/web_output.cc, but I haven't verified changing this fixes the problem. Thanks

When a OSM tag's value (or even key ?) contains a * the query returns nothing.

The former XAPI syntaxe says it should be escaped with *
http://wiki.openstreetmap.org/wiki/Xapi#Escaping

But it doesn't work with Overpass XAPI translator :
wget "http://www.overpass-api.de/api/xapi?*[designation=\*\*\*]" -O -

If that is intendend, I can fix the Overpass XAPI translator's documentation
If there is another way to escape * same
if that can be fixed, perfect ;-)

Is it possible to query the API using geometries other than a bounding box?

I'm wondering why this is prohibited.

Wouldn't this (which fails with the error above):

  <query type="area">
    <coord-query .../>
    <has-kv k="admin_level" v="8"/>
  </query>

be exactly the same as this (which runs just fine):

  <coord-query .../>
  <query type="area">
    <item/>
    <has-kv k="admin_level" v="8"/>
  </query>

The OverpassQL query way.a.b throws a syntax error:

Error: line 1: parse error: ';' expected - '.' found.

The following equivalent xml query works as expected

<query type="way">
  <item set="a"/>
  <item set="b"/>
</query>

Reminder to self: Check that as much runtime errors as possible get HTTP code 503 instead of HTTP 200.

First off, thanks for this great service.

This is the query I'm looking for:

http://tinyurl.com/btqwaet

It looks for the area with a tag wikidata=Q58253 which it finds, and towns inside it which it doesn't find (although there are towns in there).
If I replace the wikidata tag with another admin boundary, it works:

http://tinyurl.com/d76n2dn

But even more interestingly, if I search for the first boundary by it's name, it finds it and finds the towns:

http://overpass-turbo.eu/s/E

Am I doing something wrong?

Janko

The output from overpass' xapi compatibility layer is not compatible with the Xapi output as defined on http://wiki.openstreetmap.org/wiki/Xapi in the following way:

With xapi output the planet date is encoded into the output XML as a xapi:planetDate attribute on the osm element.

As an example, see this output XML from the wiki

<?xml version='1.0' standalone='no'?>
  <osm version='0.6' generator='xapi: OSM Extended API' 
   xmlns:xapi='http://www.informationfreeway.org/xapi/0.6'
   xapi:uri='/api/0.6/node[amenity=hospital]'
   xapi:planetDate='200803150826' 
   xapi:copyright='2008 OpenStreetMap contributors' 
   xapi:instance='zappy2'>
    <node id='672180' lat='48.2111685091189' lon='16.3035366605548' timestamp='2006-09-11T16:28:25+01:00' version='1' changeset='10968'>
      <tag  k='amenity' v='hospital'/>
      <tag  k='name' v='Wilhelminenspital'/>
    </node>
    <node id='3596186' lat='53.4633699598014' lon='-2.22667910006381' timestamp='2007-06-21T17:10:58+01:00' version='2' changeset='2213'>
      <tag  k='amenity' v='hospital'/>
      <tag  k='name' v='Manchester Royal Infirmary'/>
    </node>
    ...
  </osm>

In XML-queries one can already use xml-escapes in order to escape unicode characters. It would be nice to have a similar escaping method also in QL. A possibility would be supporting js/json-like escapings for that (i.e. "\u####").

This is strange, I don't understand why there should be a difference in unicode parsing depending on the pattern syntax, but that is what indeed seems to be happening.

You could for instance try:

<osm-script timeout="900">
  <query into="_" type="way">
    <has-kv k="highway"/>
    <has-kv k="name" regv="^[Ss][Tt][Aa][Bb][Bb][Ee][Ss] [Vv][Ää][Gg]$"/>
  </query>
  <union>
    <item />
    <recurse type="way-node"/>
  </union>
  <print/>
</osm-script>

and compare it to:

<osm-script timeout="900">
  <query into="_" type="way">
    <has-kv k="highway"/>
    <has-kv k="name" regv="^[Ss][Tt][Aa][Bb][Bb][Ee][Ss] [Vv](Ä|ä)[Gg]$"/>
  </query>
  <union>
    <item />
    <recurse type="way-node"/>
  </union>
  <print/>
</osm-script>

The following query returns xml instead of json:

<!-- foo bar -->
<osm-script output="json">
  <id-query type="node" ref="123456789"/>
  <print mode="meta"/>
</osm-script>

It works when there is no comment at the begin of the script or if the xml-header (<?xml version="1.0" encoding="UTF-8"?>) is explicitly provided.

(Use the query form for reproducing - overpass turbo adds the xml-header internally.)

I didn't see similar problems with OverpassQL queries, so it must have something to do with how the XML queries get parsed.

for intersection analysis (way crosses another way), I'm using the "around" statement like in the following test case:

http://pastebin.com/raw.php?i=E1zKLPzA

This query runs for about 22s. perf results suggests that most of the time is spent in the following locations:

Events: 9K cpu-clock
47,48% osm3s_query libm-2.15.so [.] sincos
13,80% osm3s_query osm3s_query [.] cartesian(double, double)
13,54% osm3s_query libc-2.15.so [.] 0xdbcc2
5,08% osm3s_query libc-2.15.so [.] malloc
4,04% osm3s_query osm3s_query [.] great_circle_line_dist(double, do
2,99% osm3s_query libm-2.15.so [.] 0x9875
2,75% osm3s_query osm3s_query [.] _Z10cross_prodRKSt6vectorIdSaIdEE
2,58% osm3s_query osm3s_query [.] intersect(double, double, double,
2,00% osm3s_query libstdc++.so.6.0.16 [.] operator new(unsigned long)
1,32% osm3s_query libc-2.15.so [.] free

In [1] you suggested to have an additional "around:0" semantics to specifically target intersection checks, where some of the 'great_circle_line_dist' calculations might no longer be required. Possibly this would result in quite a large performance boost for this query.

[1] http://forum.openstreetmap.org/viewtopic.php?pid=300329#p300329

See also http://lists.openstreetmap.org/pipermail/dev/2011-December/023885.html
I need the "version" of each node when loading with the XAPI layer of Overpass.

After digging through mailing lists I found the [@meta] qualifier that works:
overpass-api.de/api/xapi?node[amenity=drinking_water][bbox=-122.37275,37.82159,-122.17275,37.92159][@meta]

The documentation of this qualifier has moved since the above forum post was written, and I could not actually find it anyhere including http://harrywood.co.uk/maps/uixapi/xapi.html

Could this get a bit more love?

Hello :)

This program can output JSON. That's cool.

But I was wondering why wouldn't it output GeoJSON? It would be even more cool if it could. It would be possible to add Overpass query URLs as GeoJson layers to Leaflet, for example.

Unfortunately, I don't know C++ and cannot derive the answer from the code. I'm sorry.

Thank you.

consider the following query:

<osm-script output="xml">
  <query type="area" into="areas">
    <has-kv k="tourism" v="camp_site"/>
    <has-kv k="addr:country" v="IT"/>
  </query>

  <foreach from="areas" into="a">
    <print from="a" mode="ids_only"/>
    <area-query from="a" into="nodes"/>
    <query type="node">
      <item set="nodes"/>
      <id-query type="node" ref="420209169"/>
    </query>
    <print mode="ids_only"/>
  </foreach>
</osm-script>

The area-query inside the foreach loop doesn't work as expected: It prints the node 3 times, even though this node is only inside one of the areas. It seems like the loop-variable is not updated properly during the loop for the area-query command (one gets n times the same output as for the first area in the loop).

Please add support for JSONP to deal with same origin policy restrictions.

Given a taginfo result like:
http://taginfo.openstreetmap.org/tags/amenity=drinking_water%0A

The overpass query generated is either:

example://overpass-api.de/api/xapi_meta?[amenity%3Ddrinking_water%0A]
or
example://localhost:8111/import?url=http%3A%2F%2Foverpass-api.de%2Fapi%2Fxapi_meta%3F[amenity%253Ddrinking_water%250A]

Neither of which load the proper object.

See also https://trac.openstreetmap.org/ticket/5004

What I'm trying to do is first get some nodes in a bbox, and then filter that nodes to a certain area.

<query type="node">
  <bbox-query .../>
  <area-query .../>
</query>
<print/>

Sometimes this gives the expected result, sometimes only parts of the nodes are filtered, sometimes none at all (examples below).

I know I could run the query the other way round (first searching by the area, then filtering by bbox), but that can be a large performance drawback in some use cases (when the bbox-query returns significantly less data than the area-query).

1. Example query where the result is as expected:
   
2. Example query where only parts of the nodes are filtered (only the nodes on the left belong to the area):
   
3. Example query where the result is not filtered at all (note that none of the nodes are inside the area):
   

As far as I see, one can only run one single instance of Overpass API on a single machine.

This could be a problem if different users want to run Overpass API instances on a shared server or if one wants to maintain multiple databases.

Union definition describes
{1} (node[name="Foo"];way[name="Foo"];);
and
{2} (node[name="Foo"];way[name="Foo"];)->.a;
as being equivalent with the exception that the latter stores the result in ".a".

However a test executing
{1} (._;>;); out;
and
{2} (.a;>;); out;
for those two cases shows that the two sets are not equivalent.

I suspect they should be?

While trying various commands I found that if named sets are 'reunionised' and redirected to the default set, i.e.
{2'} ((.a);>;); out;
then the results yielded by case {1} and {2'} are equivalent.

When a "runtime error" happens, it is provided as a <remark> in the xml output format. For example:

<remark> runtime error: Query timed out in "query" at line 2 after 3541 seconds. </remark>

Neither this remark nor any other kind of information is provided if the same query times out with the output format set to JSON.

Example: xml vs. json

P.S. What does the number of seconds in the timeout-remark actually mean? In this example, the query clearly times out way before 3541 seconds ;)

Sometimes one is only interested in the tags that filtered objects have, but not their coordinates, way-nodes and members. Currently one can only use the body output mode, resulting in a substantial overhead for this use-case. A new tags-only output mode would solve this elegantly.

See: openstreetmap/iD#1752 (comment)

Apparently overpass does not properly handle invalid regular expressions for regv=* queries.

way["k"~"*"];

This query should return some meaningful error message (such as: "*" is an invalid regular expression!), but it returns an "Internal Server Error" on overpass-api.de and an empty data set on ramber.ru.

query http://overpass-turbo.eu/s/1jf returns exactly one object. If one additionally adds a (narrow) bbox-query, the object isn't found: http://overpass-turbo.eu/s/1jg

As I haven't noticed this behaviour before I guess it could be related to the "empty tag" selector?

I would be really interested to have binary data from Overpass-API. Is PBF output a priority task? Otherwise I would look into implementing this feature.

Hi Roland,

First of all, thanks for providing Overpass API! It's working really well for me :-)

I'm using the query language to occasionally download data from one of the public servers. I choose the server based on polling them beforehand to see which gives the fastest response.

Question/Report:
With the original API and XAPI I can send a boundingbox request using HTTP HEAD (to limit the bandwith use), but with overpass it seems I'm getting a 400 Bad Request. Ironically, when I send a XAPI request on the XAPI compatibility layer it works fine.

Maybe I'm missing something but is it true that this is not supported yet? And if so, can I hereby add this as a feature request? :-)

Thank you in any case for taking the time to respond to this!

Jurrian

ps: Example URL that works with POST, but returns a 400 on HEAD:
http://www.overpass-api.de/api/interpreter?data=(node (52.04926820919696, 4.276337673845001, 52.06077954280921, 4.2950582001784365);<;>;); out meta;

Hi there

Thanks for the amazing work on this. :)

I'm struggling to craft a query and unfortunately the OSM wiki doesn't provide an example of what I'm trying to do, so I figured you might be able to help me here. ;)

I wan't to do a "near" query with (around:xxxx) of any named roads around a point. This is the kind of pseudo-syntax I've got

({{center}});
way
  ["highway"]
  ["name"]
  (around:700);
out body;

My problem is on the first line. I'm trying to create a "virtual node" as starting point for my query, using just a latitude and a longitude value, but I can't figure out if that's possible from the wiki description, or whether I first need to find a specific node to start my "near" query from.

Can the is_in thing help here? Or can I make a single-point polygon to start my search from?

Thanks!

This query returns not the bbox but the whole earth. ("way" is ok)

<bbox-query {{bbox}}/>

query type="area"> has-kv k="amenity" v="library"/> bbox-query {{bbox}}/> /query> print/>

way(pivot); and relation(pivot); as well as area(pivot); all give the same result. Only node(pivot); returns an empty set.

I found nothing in the documentation on this topic:
In 'rel' should only relations be selected that have the type 'building' - is this possible with the current 'API'?
This should select the complete buildings that have a 'roof' or contain 'building:part'

 <union>
<query type="way">
  <has-kv k="roof" v=""/>
  <bbox-query {{bbox}}/>
</query>
<query type="way">
  <has-kv k="building:part" v=""/>
  <bbox-query {{bbox}}/>
</query>
</union>

<query type="relation" into="rel">
    <recurse type="way-relation" />   
    <!--<has-kv k="type" v="building"/>-->
        <!--<has-kv k="role" v="building:part"/>-->
</query>

<recurse type="way-node" into="nodes"/>
<union>
<item/>
  <query type="way">
  <recurse type="relation-way" from="rel" />
    <has-kv k="building" v=""/>
  </query>

 <query type="way">
  <recurse type="node-way" from="nodes" />
    <has-kv k="building" v=""/>
  </query>
</union>

<union>
  <item/>
  <recurse type="way-node"/>
  <item set="rel" />
</union>

<print mode="meta"/>

When issuing a bad XAPI query, like http://overpass-api.de/api/xapi?*[source~bing], HTTP/1.1 200 OK is returned.

<has-kv> with an empty string for v behaves like <has-kv> without v, thus searching for arbitrary values of the tag rather than searching for empty tags:

http://overpass-turbo.eu/s/ZW

The behaviour for a similar OverpassQL query (node["k"=""]) is even more strange:

http://overpass-turbo.eu/s/ZX

The area-query statement currently also returns ways that form the inner boundary of multipolygons or touch inner or outer border(s) of the area. See this example. This is quite contra-intuitive.

Also, this behavior isn't really what the documentation says:

Ways are found if at least one point (also points on the segment) is properly inside the area. A way ending on the border and not otherwise crossing the area is not found.