Contribute to project

LearnOverpass

Intro

By Area Improve page

“Bingo!” Bob says as he walks towards the restaurant.

See how powerful the Overpass QL is in querying OSM data? It has a plethora of different filters and statements, and combining them with each other can create even more specific queries for your use cases.

Our previous example introduces a very important metaphor in the Overpass Query Language, which is ‘flow’. A good way to think of the Overpass API is that it allows OSM data (nodes, etc.) to be generated and modified as it ‘flows’ from one statement to another. 

As a concrete example, our bounding box query (the lat/lon points) finds the nodes in that area. The resulting data will then ‘flow’ and get filtered [natural=tree], [height=20], etc.

If you notice, (around:n) works the same way, in that our initial data flows in it, and gets modified to show the nodes around the initial data that is produced by our first line.

“Wow!” Bob exclaims, “That was a very good meal!”

“That would be 25 Euros sir” says the waiter, dressed in an all white attire.

“Coming right up!” Bob says proudly, when…

“Uh oh! I seem to have left my wallet at the observatory!”

Flustered, Bob ran outside the restaurant, hoping to get back to his wallet.

Instructions
  1. Bob left his wallet as he was touring the city! He distinctly remembered leaving his wallet at a certain observatory tower in the Inn river.
  2. That observatory is quite a far away, so it would be better to make sure that our resulting query also shows our current position (so we don’t get lost!) If you notice in the editor on the right, we have two out statements, with a blank line in between them. Overpass QL can use multiple out statements. If you think of QL statements as sentences, you can think of our structure here as two different paragraphs. Our first ‘paragraph’ is the query we’ve been using so far, and only prints the restaurant where Bob is. The second ‘paragraph’ is what you need to edit.
  3. We need to find a node that is an observatory tower. We can use the filter ["tower:type"=observation] for this. Note how we surround the filter type with quotation marks - we do this since it contains a non alphabet character (namely :)
  4. Finding observatory tower nodes is easy, but how can we limit our results observatories in the Inn river? Using a bounding box would be too tricky. What we can opt to do is to query by area. Since we know that the tower is in a particular area (Inn River), we can use that info in making our query.
  5. As you can see in the editor, the 5th line has the area keyword. This is just like the keyword node we have used so far, but instead of querying for a single point of interest like a node, area queries for a… well, an area!
  6. We know that the name of the river is Inn. We can use this as a filter for our area. Go ahead and use [name=Inn] as a filter in the area statement.
  7. We don’t really want to query for the area, instead, we just want to use the area to find a particular node in it. So in the sixth line, type in your  node statement, along with the tower type filter discussed in 3.
  8. Once that’s done, we still need to make sure the node only queries inside the area we defined. To do this, change your bare node statement to node(area). This tells overpass to only query for nodes inside the area you defined on the area statement!
That doesn't seem right! Remember to use an area query!
Awesome Work! Go to Next Lesson
Run Query Reset Code
Data
node(48.5657094, 13.4490548, 48.5662416, 13.4501676)[natural=tree][height=20]; node(around:450)[amenity=restaurant]; out; area[name=Inn]; node(area)["tower:type"=observation]; out;