Talk:Overpass API/Language Guide

Comments

I just tried, and it seems Overpass QL supports comments with //. I'm assuming this is intended, and have added this to the page. In your conversion script, can you also convert comments between this style of XML style? -- Joshdoe 10:01, 15 March 2012 (UTC)

Search by timestamps

Is it possible, for example, to find the latest object with a given tag? There's no mention of timestamps in the API documentation. --Zverik 08:50, 10 May 2012 (BST)

JSON Syntax

The JSON Syntax is the same as GeoJSON but uses different names. Replacing this names with geojson names would be easier to read for openlayers, leaflet,...

{
  "type":"FeatureCollection"    //<---- insert this line
  "version": 0.6,
  "generator": "Overpass API",
  "osm3s": {
    "timestamp_osm_base": "2012-10-12T00:46:03Z",
    "copyright": "The data included in this document is from www.openstreetmap.org. The data is made available under ODbL."
  },
  "elements": [  // <---- features instead of elemens

{
  "type": "node",  //<------Feature instead of node
  "id": 371597317,
  "lat": 50.7412721, //<-- delete this line
  "lon": 7.1927120,  //<---- delete this line
  "geometry":{"type":"Point","coordinates":[7.1927120,50.7412721]}   //<-- add this line
  "tags": {   //<----- properties instead of tags
    "is_in": "Bonn,Regierungsbezirk KÃ¶ln,Nordrhein-Westfalen,Bundesrepublik Deutschland,Europe",
    "name": "Gielgen",
    "place": "suburb"
  }
 }
]
}

geojson does not know nodes as known in OSM XML Format. It is not possible to transform osm xml format to geojson without losses. To display the data on a map we do not nead the node ids. If an editor like Potlatch or josm reads the format it needs the id. To avoid this limitation the format could be extended like this:

//geojson_withnodeid
{type:FeatureCollection,
nodes:[
{"123633":[16.343,48.233]},  //<--{id:[longitude, latitude]}
{"123634":[16.341,48.232]},
{"123638":[16.342,48.233]},
]
features:[
   {
      "type":"Feature",
      "geometry:{
          "type":"LineString",
          "nodes":[123633,123634,123638]   //<--- array of id's
      }
   }
]
}

File size does not get smaller. If an editor uses this osm api it needs the ids.

Robotnic 01:58, 12 October 2012 (BST)

Or, alternatively, would it be possible to have an additional output format that complies with geojson standards? I understand the main difference (except changing names) is that overpass json defines polylines and polygons by referencing their nodes, while geojson requires a list of coordinate pairs directly within the LineString or Polygon object. Thus, this additional format would not be suitable for editing.--G0ldfish 13:41, 28 November 2012 (UTC)

GeoJSON as an additional output format would clearly be possible. The main problem is not the renaming, but the mapping of datatypes: there is no polygon datatype in OSM, so the only geometries that can be used are points and polylines. On the other hand, there is no representation for OSM relations in GeoJSON, so this data must be discarded. The hope that there is an extensible and compatible solution for this conversion problems is the main reason not to introduce a premature variant of the format now. --Roland

Um, yes, I think some features could be mapped, e.g. closed ways to either LineStrings or Polygons (not without difficulties though as the meaning of closed ways in OSM need examination of the tags), and multipolygon relations with one outer ring to Polygons, but I have to agree that a lot of osm objects do not fit into the geojson concept. Too bad.--G0ldfish

GeoJSON is best constructed on client side out of OSM data, if you ask me. As Roland says, it may work for a limited set of use cases, but as soon as you get to relations (routes, multipolygons) it gets very hard. Note that there is a point where there is no more 1 to 1 relationship between OSM data and its geoJSON representation: A multipolygon is a single "feature" in geoJSON, but multiple objects in OSM (the relation plus all of its ways).

That said, there is already some code that does this OSM to geoJSON conversion: E.g. (in javascript) the data view of openstreetmap-website or (also in JS) (if you also want some very basic multipolygon support) at overpass-ide.

Wishlist: numeric comparisons

Would it be possible to allow numeric comparison like greater than, lesser than? This would be easier to understand (and might be more efficient?) than having to use a regular expression to match a range of numbers I think.--G0ldfish 16:56, 17 October 2012 (BST)

It would be cool if you could use numeric operators, like in " ["width">7] or ["fee"<10] --Gormo (talk) 11:08, 16 August 2013 (UTC)

That's a good idea. I'll add it along with some other extended search operators. As I work currently on the area features and large Node ids, please don't expect this to be done before end of January. --Roland

Issue is now being tracked as Github Issue #78 for Overpass API. Please add any comments/requirements there. Mmd (talk) 17:49, 29 June 2014 (UTC)

Search with wildcard

Ist there a way to use wildcards in searching for keys or values? Like node["name"="Giel*"]; or node["name*"]; --Brogo 08:46, 19 October 2012 (BST)

node["name"~"^Giel"];out; finds all objects whose name begins with "Giel".

node["name"~"^Giel.*n$"];out; finds all objects whose name begins with "Giel" and ends with "n".

node["name"](50.7,7.0,50.8,7.1);out; finds all nodes that have a "name" tag within the given bounding bix. In theory, a global search works also, but given the fact that this search has some hundret million results, it is too big. -- Roland

OK fine, and if I would like to search for the key name* to get name, name:de, name:fr etc. I have to use node["^name"];out;. Is this correct? --Brogo 10:06, 19 October 2012 (BST)

No, I've tried it and didn't work. It seems that there is no wildcard-search for keys. Could you please implement this? --Brogo 15:43, 23 October 2012 (BST)

This issue is now being tracked on Github, Overpass API issue #59. Please check this ticket for progress or additional requirements. Mmd (talk) 17:46, 29 June 2014 (UTC)

Wish: extend search value for ways

Would it be possible to extend the value for way selection with something like <has-rel k="network" v="ncn"> . Currently if I search for a relation within a bounding box , and recurse the ways into the output all ways belonging to the relation are returned. There is no method to restrict the result. But there is also no method to limit ways within a boundingbox to those belonging to a relation. When using overpass and openlayers to display a relation-network far more data is fetched than needed to display within the boundingbox. --Noordfiets 11:06, 26 November 2012 (UTC)

That's already possible. For example, assume you want of bus line 603 only bus stops that have a "str" in their name:

[out:json];rel[network=VRR][ref=603];node(r);out;

gives all bus stops, but

[out:json];rel[network=VRR][ref=603];node(r)[name~"str"];out;

is restricted to bus stops fulfilling the given name criterion.

Likewise,

[out:json];rel[network=VRR][ref=603];node(r)(51.25,7.1,51.3,7.2);out;

limits the bus stops to all northern of latitude 51.25.

More in general: All clauses are freely combinable.

--Roland

That's right and I use it for nodes that way. But routes such as cycling or hiking are made up out of ways rather than nodes.

(relation[network=LF14](bbox);way(r);node(w););out skel;

This finds the relation within the bbox and than returns all ways belonging to the relation, including the ones outside the bbox.

What I would like is a way to find the relation in the bbox, and than return only the ways that a:belong to the relation b:are

inside the bounding box.

I've studied and experimented but fail to see how this can be done with the current syntax.

--Noordfiets 08:54, 27 November 2012 (UTC)

I haven't found any relation with "network=LF14", so I come back to the previous example:

[out:json];rel[network=VRR][ref=603];way(r)(51.25,7.1,51.3,7.2);out;

reduces the ways to the corresponding bounding box.

Your example would transform to

(relation[network=LF14](bbox);way(r)(bbox);node(w););out skel;

although it has currently an empty result set. Please note that this still leaves some nodes outside the bounding box, because ways that intersect the border of the bounding box are always completely included. You can remove this extra nodes with

(relation[network=LF14](bbox);way(r)(bbox);node(w)(bbox););out skel;

--Roland

It should have been "ref=LF14" sorry. Anyway, it came back to a complete misunderstanding of the bbox-query on my part

I'm most ashamed but happy now: it's working and I hopefully have reduced my load on the server.

Many thanks for spending time on my question and beeing so patient.

( since this does not seem to have much use in this 'talk' anymore You might as well delete the item after reading )

--Noordfiets 16:43, 27 November 2012 (UTC)

Wish : centroid

In many cases POIs are nodes or ways. In many case, on maps, we need only the centroid, to display (a circle is more visible at low zoom than a micro polygon), to gather in cluster strategies... Having a centroid output would ease making dynamic maps like uMap. So

node({{bbox}})[amenity="restaurant"];out;
way({{bbox}})[amenity="restaurant"];out;
>;out skel;
relation({{bbox}})[amenity="restaurant"];>;out;
>;out skel;
out body;

would become something like

node({{bbox}})[amenity="restaurant"];out;
way({{bbox}})[amenity="restaurant"];out centroid;
relation({{bbox}})[amenity="restaurant"];out centroid;
out body;

--FrViPofm (talk) 14:00, 14 December 2013 (UTC)

+1
+1

CristianCantoro (talk) 20:46, 21 December 2013 (UTC) Larry0ua (talk) 10:19, 12 April 2014 (UTC)

This feature is available since Overpass API v0.7.50. However, is does not return the centroid but the center point of the inner bbox, which should be fine for most applications. Please refer to Overpass QL - out statement for more details.

out center;

Mmd (talk) 17:43, 29 June 2014 (UTC)

. (dot value)

What exactly a dot for a value means ?
For example in ["highway"!~"."]
Does it stand for "any value" ?
Would be fine if explained in the article...

The knife (talk) 07:51, 8 August 2014 (UTC)

Page overhaul

Hi all. Following a message on the help forum, I've taken the liberty to re-structure this page a bit. See what you think.

The section "Combining_results_with_the_union_operator" needs more work: It introduces the idea of sets, that isn't really explained, but used in the next section. I've also found the idea of sets unclear on Overpass_API/Overpass_QL. Could somebody add some examples there, and explain it?

I would also suggest that the section "More complex recursion" is moved elsewhere.

Bjohas (talk) 17:31, 2 July 2016 (UTC)

out; vs. out body;

Are those the same? Bjohas (talk) 17:31, 4 July 2016 (UTC)

Difference between these queries

Is there a difference between

(
abc;
);
>;

and

(
abc;
>;
);

and

(
abc;
);
(._; >;);

? Bjohas (talk) 18:05, 4 July 2016 (UTC)

Why no explanation of (bn), (bw), (br), (<), (<<), etc.

It is nice to mention these syntaxes and hint that they relate to recursion, but can't they each at least be given a one-line explanation of what they do? The explanation of recursion in general is pretty lacking... AgentFriday (talk)

Possibity of adding a foreach statement inside a union statement

In the Union and assigning sets: .->a section there are two contradicting paragraphs:

   Inside the union, any sequence of statements can be placed, including nested union and foreach statements.

and

   Limitation : Note foreach and print statements cannot be sub-element of element union.

Eliminate this page?

There is a box at top that it is outdated. Is there any good reason to keep it given presence of both Overpass API/Overpass QL and Overpass API/Overpass API by Example?

I plan to review its content and remove sections already covered on one of this pages, and at the end redirect it to Overpass API/Overpass QL and remove from navigation template.

Mateusz Konieczny (talk) 20:26, 23 May 2020 (UTC)