Overpass API User's Manual

Spatial Data Selection
Find Objects
Counting Objects
Analysing data
More information

Data Formats

There are multiple data formats to carry OpenStreetMap data. We present all that have an immediate application.

Scope

The data types have already been introduced in the corresponding section of the preface. Thus, you should already know nodes, ways, and relations here.

The frequent problem how to complete the geometry of OpenStreetMap objects is addressed in the section about geometries in the chapter Spatial Data Selection.

Traditional Degrees of Detail

We start with the degrees of detail: While the general output format is controlled by a per request global setting, the degrees of detail are controlled per output statement by its respective parameters. That way it is possible to mix multiple degrees of detail in a single request. This capability is needed to get an optimal amount of data for some geometry variants. In addition, the respectively best output mode is told at each application.

We present for each degree of detail an example around the suburb Greenwich in London. All examples are crafted to return rather few nodes, ways, and relations to facilitate to inspect the data in the tab Data of Overpass Turbo.

For the original degrees of detail of OpenStreetMap there is a hierarchy to turn them on:

The statement out ids delivers:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out ids;

The statement out skel delivers in addition the necessary information to reconstruct the geometry:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out skel;

The statement out (without a flag) delivers the complete geodata, i.e. in addition:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out;

The statement out meta delivers in addition:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out meta;

Finally, the statement out attribution delivers the following data:

This last degree of detail acts on data that falls, with regard to the dominant societal consensus, into privacy concerns. For this reason there is a barrier to obtain that data. As none of this data is necessary for the applications discussed in this chapter, we refrain from an example here.

Additional Data

It is possible to amend the output by three different amounts of geometry data. Any combination between the just presented degrees of detail and the extra geometry is possible.

The flag center triggers the addition of one coordinate per object. This coordinate does not have a sophisticated mathematical meaning, but is just in the middle of the bounding box that encloses the object: example 1

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out ids center;

example 2

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out center;

The flag bb (for bounding box) triggers the addition of the bounding box for each way and relation: example

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out ids bb;

The flag geom (for geometry) amends the ways and relations with coordinates. For this to work, the degree of detail must be at least skel, and it works up to attribution: example

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out skel geom;

Now we received not only some hundred meters from a park nearby Greenwich, but several hundred kilometers footways in eastern England. This is a general problem of relations. As a remedy, a bounding box also for the output command can be set, see here.

Finally, there is the output format tags. This is based on ids and shows in addition all the tags of an object but no geometries or structures. First and foremost, it is useful if one does not need the coordinates in the result:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out tags;

It can also be combined with the two geometry flags center and bb:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out tags center;

JSON and GeoJSON

Now we turn to data formats: While the degree of detail can be selected per output command, the output format can be declared only globally per request. In addition, the choice of the output format only changes the form but not the content.

In JSON we arrive that way in the middle of a conflict. On the one hand, there is a quite popular format for geodata in JSON, called GeoJSON. On the other hand, the OpenStreetMap shall keep their structure, and this structure does not fit into the data model of GeoJSON.

As a solution, there is a possibility to create GeoJSON conforming objects from OpenStreetMap objects. However, the original OpenStreetMap objects are faithfully represented in JSON and are not GeoJSON.

OpenStreetMap objects in JSON:

[out:json];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out geom;

Derived objects in GeoJSON:

[out:json];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
convert item ::=::,::geom=geom(),_osm_type=type();
out geom;

The creation of derived objects is a big subject with its own chapter.

CSV

Being capable to organize data in a table is often useful. For OpenStreetMap this means columns selected by the user and one line per found object.

The choice of the columns properly restricts for most of the objects the information that is available about the object. E.g. tags not requested as a column get lost in the output. Geometries that are more complex than a single coordinate also cannot be printed in this format. This is a difference to the potentially faithful formats XML and JSON.

The standard case of a column is to be the key of a tag. It is then printed for each object the value of the tag with this key on the object. If the object does not have that key, then an empty value is printed. For the further properties of an object there are special column header declarations; these start with ::: example

[out:csv(::type,::id,name)];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out center;

The abbreviation CSV used to mean comma separated value. But the various applications using this format have developed differing expectations what constitutes a delimiter. Thus, it is possible to configure the delimiter as well as it is possible to turn the headline on or off:

[out:csv(::type,::id,name;false;"|")];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out center;

At each application it is indicated which variant fits.


next: Overpass Turbo