My objective: select all buildings within residential landuse ways and relations in a municipality, as follows (query below):
- Select municipality by
geocodeArea;
- Select
landuse=residential ways and relations, with note tag;
- Show outlines of areas found in the step 2 on map;
- Select buildings (ways and relations) within the areas found in the step 2;
- Show selected buildings on map.
Results:
- 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,
Igor
1 Like
milet
(Milet)
2
It seems like the skipped relations don’t have a name tag.
Relations where buildings are found, do have a name.
2 Likes
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.
IlBano
4
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
IlBano
5
Found right now that the “issue” was already submitted
2 Likes
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