Getting Started With Overpass Turbo – Part 1

The Open Street Map database contains detailed information about almost every square metre of the surface of the planet. Land use, building types, rivers, park benches, pubs, streets and millions of other data points are all mapped out and documented in detail.

You might be familiar with the browser-based Open Street Map (OSM) website. Superficially it resembles mapping services like Google or Bing, but you may not be aware that the huge mapping dataset that powers it can also be accessed directly. Need to find all the power lines in a city? Count the number of pubs per square kilometre? Visualise COVID cases region by region? Or maybe you just want to solve a Quiztime puzzle? OSM’s vast database can be queried to support almost any mapping use case you can think of.

The OSM database can be queried via an API called Overpass. It’s very powerful but it isn’t very beginner friendly and constructing queries requires a little coding knowledge.

A more accessible way to access Overpass exists in the form of Overpass Turbo. Overpass Turbo allows you to build Overpass queries in a much more user friendly way. You can build the query, run it, and then see the data represented on the map. The results can also be returned in a CSV or JSON format, which makes incorporating them into your own mapping projects much easier.

Basic Concepts

Although Overpass Turbo is more user friendly than querying Overpass directly, it is nothing like as easy to use as Google Maps for example. It is much more powerful than Google Maps, but constructing effective queries requires an understanding of the data types that OSM contains.

The syntax is also much stricter. If you enter “five star hotel near Disneyland” as your Overpass Turbo query, you won’t get very far.

It’s worth spending a short time getting familiar with the basic types of OSM data before starting to build queries.

Geometries

There are three main types of object in the OSM database. These are known as geometries. Every object represented on an OSM map is one of these types.

Node

A node is a single point on a map. It has a unique ID number and a set of coordinates. This park bench next to a canal in the city of Osnabrück is a single node:

You can see it has a unique ID number, lat/long coordinates, and some tags that describe its properties. We’ll discuss tags shortly.

Way

Next to the bench is a railway line. Linear features cannot be represented by a single node on a map, so paths, roads, rivers and motorways are represented by multiple nodes linked together to form a way. A way is just a collection of linked nodes.

Ways do not just have to be linear like railways or canals. A collection of nodes can start and end on the same point to form a shape. This airfield just outside Osnabrück is not a node, but a way. Its boundary is defined by a series of single nodes linked together to form a polygon:

So to find objects that are greater than a single point on a map, it is necessary to search for ways and not just nodes. We will see shortly that there is a way to combine these kinds of query, but we need to look at the final data type first.

Relation

A node is a single point. A way is a series of linked nodes. A relation combines ways and nodes to form more complex objects.

Let’s say that you want to represent a train route in OSM. You have nodes (stations, signals) and ways (track sections, bridges, perhaps larger stations). To represent the route would require combining these nodes and ways into a single “route” object. These kind of combinations are known as “relations”.

Let’s go back to Osnabrück. The Hafen area is an administrative district in the north of the city. In OSM it is a collection of ways that mark the geographic boundary and also a single node denoting it is an administrative centre. It is too complex an object to be either just a way or just a node, so the nodes and ways are combined to form a relation.

Multiple ways form the boundary. The single node in the middle refers to the administrative centre. This can be seen in the info panel in OSM (right click on the map and click “query features”):

The Hafen area is a relation made up of 5 ways and a single node.

Tags

Tags are the key to finding information in OSM. As we’ve just seen, every object in OSM is either a node, way, or a relation. These objects contain location data but they do not contain descriptive information. Nodes, ways and objects are labelled and described with a series of Tags.

The first object we looked at was a park bench. It’s a node with a unique reference number of 4340279543 and lat/long coordinates of 52.2910290, 8.0265765. That is all the information a node needs to exist – but how could anyone ever find it or even know what it was based on those details alone?

OSM objects need additional information in order for them to be described and indexed properly. Tags are used to do this. The bench has several tags to describe it:

This is a very powerful system, but there is one difficulty with tags. In Overpass Turbo I cannot just do a freetext search like “park bench” and be certain that I will find a matching tag. The tags I use to search have to match exactly with the tags as they were assigned by OSM contributors, so if I just guess the tag name I will probably be wrong and I won’t find what I’m looking for. Overpass Turbo’s Query Wizard can help slightly by suggesting tags based on search terms, but it pays to know how tags are constructed in order to be as accurate as possible with your results.

TagInfo

OSM’s Taginfo site allows you to search for tags that have already been added to the database. Using the search box in the top right we can search for the keys and values that make up tags so they can be added to our queries.

Let’s say that I want to find wind turbines. I enter the term “wind turbine” into the Taginfo search box and get these results.

OSM Tags are always made up of a key-value pair. You can think of keys as a main type, and values as a subtype. Examples of common key-value pairs might be building=school, or highway=motorway.

This means that just creating a tag called “wind turbine” won’t work in OSM. The tag must have both a key and a value.

The image above shows how people have created key-value pairs to describe wind turbines. By far the most popular is the tag generator:method = wind_turbine.

You can see the tag is comprised of the key generator:method and the value wind_turbine. You can also see that there are 240,052 objects in the OSM database that are tagged this way, so to find a wind turbine this will be the best tag to use. By contrast if I searched with the tag name = Wind turbine this would only match 18 objects in the entire database, so I’m unlikely to find what I’m looking for.

Here are all the results for the generator:method = wind_turbine query in Osnabrück:

Bounding Boxes

Before putting these concepts into action it’s important to mention the concept of bounding boxes. When querying Overpass it is necesary to set a North, South, East and West boundary point of the box you wish to search in. These are normally defined with coordinates sent to the API, but fortunately Overpass Turbo creates this box for you based on the map area in view in the right hand window. The coordinates are represented by the {{bbox}} tag in the query code. Overpass Turbo will only search for data matches within the box area you specify.

Conclusion

In this post we’ve looked at the basic building blocks of OSM and Overpass Turbo. In the next post we’ll put them together to build some queries and start retrieving data.

3 thoughts on “Getting Started With Overpass Turbo – Part 1”

  1. Pingback: weeklyOSM 550 | weekly – semanario – hebdo – 週刊 – týdeník – Wochennotiz – 주간 – tygodnik

Leave a Comment

Your email address will not be published. Required fields are marked *