Inconsistent selection of buildings in landuse relations (bug?)

My objective: select all buildings within residential landuse ways and relations in a municipality, as follows (query below):

  1. Select municipality by geocodeArea;
  2. Select landuse=residential ways and relations, with note tag;
  3. Show outlines of areas found in the step 2 on map;
  4. Select buildings (ways and relations) within the areas found in the step 2;
  5. Show selected buildings on map.


  • The query found successfully all landuse ways and relations as intended.
  • 100% of buildings are found if within ways, but the query skips about 3 out of 4 relations, even if the relation was found. I don’t know why. The relations are closed.

The query: overpass turbo

To help the debugging, the ways are painted blue, and the relations in red.

Any help is appreciated,


1 Like

It seems like the skipped relations don’t have a name tag.
Relations where buildings are found, do have a name.


It seems you have a point, despite the fact the query doesn’t have any filter about objects having a name or not. If this confirms, I’ll open a bug report on Overpass GitHub.

I think @milet is right.
The script that is used for area objects creation has a rule that requires name key presence for multipolygon relations to be considered areas.

1 Like

Found right now that the “issue” was already submitted


Ouch, that is bad. Say I want to find all residential buildings in flood-prone areas, wetlands and the like in a state/province? Many of those areas, due to complicate outline, are traced as multipolygons. It’s not like I should go to every flood-prone area and give them a mock name just to make a query work (of course, I’m not going to do that).

(EDIT: Still I find questionable requiring a name “under the hood” when the statement wr[building](area.aland) says nothing about names. It’s non-intuitive/explicit behavior. It would be clearer if the overpass just threw “The query is too expensive to process”.)

Is there any practical workaround?

1 Like