Overpass API User's Manual

Counting Objects
Analysing data
More information

Per Tag

Request all objects that bear a chosen tag.

Global

We would like to find worldwide all objects that bear a given tag.

This only makes sense with the Overpass API for tags with less than 10'000 occurrences. The respective number can be found at Taginfo. For larger numbers, it can take too much time to get the data at all or the browser crashes on the attempt of showing them or both.

Searches that are spatially constrained do work well even for frequent tags.

A typical example for rare tags are names of things, here Köln (German name of Cologne):

nwr[name="Köln"];
out center;

Even after triggering the request by Execute nothing visible happens. Instead, clicking the magnifier moves the viewport to the data. We use a global viewport for all of the following requests such that you do not need to move the viewport.

Such searches can fail in seemingly straightforward cases, too. The term Frankfurt collects results all over the globe, but the biggest city of that name, Frankfurt am Main, is not found at all:

nwr[name="Frankfurt"];
out center;

Having the suffix am Main in the name hampers the city from being found. Overpass API would neglect its mission if it found an object beside that mismatch. An interpreting search constitutes a job for a geocoder, e.g. Nominatim.

Still Overpass API posesses filters suitable to catch the name with suffix, e.g. by a regular expression. We can request all objects whose names start with Frankfurt; due to the large number of hits this search takes time, but the result's size is harmless in this case despite the warning message:

nwr[name~"^Frankfurt"];
out center;

Many more typical use cases for regular expressions are elaborated on later.

These are not exactly few hits, in particular roads whose names start with Frankfurt. In most cases we search for only one of the three OpenStreetMap object types. The boundaries of a city are always encoded as a relation. We can narrow down to this object type as we replace nwr (for nodes-ways-relations) by relation:

relation[name="Köln"];
out geom;

Here the output verbosity has been changed from center to geom to show the full geometry of the object.

Correspondingly, there are the types node and way instead of nwr. They deliver only nodes respectively ways.

Finally a remark about tags with special characters (everything except letters, digits, and the underscore) in the key or in the value: The attentive reader might have spotted that the value in the tag filter is always in quotation marks. Quotation marks are suggested around keys as well, thus the request above shall strictly look like:

relation["name"="Köln"];
out geom;

But Overpass API silently wraps the key in quotation marks whenever it is clear that an ordinary literal is intended. This cannot work with special characters because special characters can have a special meaning and the user might have made a typo elsewhere in writing down the requests.

Quotation marks in literals are escaped by prepending them with a backslash.

Local

If one requests all objects with a certain tag within a certain area, then it is actually a combination of more than one filter. Combining filters is described thoroughly in Combining by And and Or and Pipelineing. Here we keep focus on certain standard use cases.

All objects in a unique area are e.g. all cafés in Cologne:

area[name="Köln"];
nwr[amenity=cafe](area);
out center;

The section Areas covers the operating mode of the first line. Our attention here goes to line two: This is a query for types nwr (i.e. nodes, ways, and relations). The presence of the first filter [amenity=cafe] determines that only objects are admissible that carry a tag with key amenity and value cafe. The second filter (area) restricts the result to objects from a certain area.

The filter (area) operates based on the step-by-step paradigm.

This way we select objects that fulfill both the tag condition and the spatial condition. These selected objects are, again by the step-by-step paradigm, available for the following statement. This prints them to the user.

If this sounds too complex to you then a different and simpler way may appeal to you: You can shape the result spatially by bounding box and combine this with a filter for a tag (example):

nwr[amenity=cafe]({{bbox}});
out center;

The central element again here is the statement starting with nwr: The filter [amenity=cafe] works the same way as before. The filter ({{bbox}}) is expanded by Overpass Turbo to the current viewport as a bounding box, and Overpass API uses that bounding box as the second and spatial filter.

The order of the two filters does not matter - it never matters for filters:

nwr({{bbox}})[amenity=cafe];
out center;

has the same result as the request before.

The target type of the query statement can and shall be selected amongst node, way, and relation here, too. For example for railway tracks only ways:

way[railway=rail]({{bbox}});
out geom;

Special

We have already desired to search in a fuzzy way, in the case of Frankfurt. Regular expressions are a very powerful tool for this. A systematic introduction to regular expressions would go beyond the scope of this manual, but it will provide a couple of examples for commonplace needs.

In some cases we know how a name starts. For example, we request here all streets whose names start with Emmy:

way[name~"^Emmy"];
out geom;

The most important character in the entire request is the tilde ~. It turns the filter in the first line into a filter for regular expressions. Now all in the database existing values for the tag with key name are compared against the regular expression that follows after the tilde.

The second most important character is the caret in the expression ^Emmy. It is part of the regular expression and ensures that only values match that start with Emmy. In total, the request could be stated as:

Find all objects of the type way that have a tag with key name and a value that starts with Emmy.

An appropriate output statement follows in the second line.

Similarly, one can search for values that end on a given value, e.g. Noether:

way[name~"Noether$"];
out geom;

The tilde ~ again marks the filter to be for a regular expression. The dollar sign $ within the regular expression defines that the value shall end on Noether.

The magnifier as a convenience feature in Overpass Turbo zooms to the single result, in Paris.

It is also possible to search for a substring that is anywhere inside:

way[name~"Noether"];
out geom;

Write down the substring without any extra special characters for this purpose.

It is slightly more difficult to search for two (or more) substrings, e.g. first name and surname, when one does not know what is between the two substrings. The names Emmy and Noether appear as divided by a space as well as by a hyphen. Regular expressions allow to state this by putting all acceptable characters in a pair of brackets:

way[name~"Emmy[ -]Noether"];
out geom;

Alternatively, one can admit any single character:

way[name~"Emmy.Noether"];
out geom;

The single dot . does the job. In a regular expression, a dot means that every string with an arbitrary character at this position is a match.

Sometimes it is necessary to admit any number of characters. One actually searches for two separated substrings. An example is the composer and musician Bach; he has beside Johann more first names:

way[name~"Johann.*Bach"];
out geom;

The two characters dot . and asterisk * shape that search term. The dot matches an arbitrary character, and the asterisk means that the expression before (here .) may repeat any times (not at all, once, or multiple times).

Another repetition operator is the question mark ?. Then the expression before (below h on first and o on second occurrence) may appear not at all or once. This helps with Gerhard respectively Gerard respectively Gerardo Mercator:

way[name~"Gerh?ardo?.Mercator"];
out geom;

The last example covers a use case that will reappear later on with the combination operators: Find a value from a given list like e.g. the standard values trunk, primary, secondary, tertiary for arterial streets!

way[highway~"^(trunk|primary|secondary|tertiary)$"]({{bbox}});
out geom;

We focus on the filter [highway~"^(trunk|primary|secondary|tertiary)$"]. The tilde ~ indicates the regular expression. In the regular expression the caret at the beginning and the dollar sign at the end enforce that the full value and not only a substring is a match to the search term. The pipe sign | represents the logical or, and the parentheses cater for that caret and dollar sign apply to the full expression and not only one of the alternatives.

Per Number

...


next: Pipeline Building