Area_to_map : too much or not enough

[Mahabarata]

Hi,

1. missing elements in the area :

I created this query : https://overpass-turbo.eu/s/1yFn

The problem is that, in the area of the relation Marshall Islands (see https://www.openstreetmap.org/relation/571771#map=6/9.579/167.003), the relation Naṃdik 3825989 (see https://www.openstreetmap.org/relation/3825989#map=6/9.579/167.003) is not listed in the result of the query and I don't understand why : this relation has the tag admin_level and is in the area so it should be selected, no ?

Same thing for the relation Enewetak 3825996 (see https://www.openstreetmap.org/relation/3825996#map=6/9.579/167.003).

In another way of speaking, the query finds the relation 571771 and only this relation (first line), changes this relation into an "area" (second line) then tries to find all relations with a specific tag that are in this area (third line) : so it finds the relation 571771 itself but not the relation 3825989 when this relation is in the area (and is part of the relation 571771 itself as a member).

For me it is incoherent that the third line finds the relation 571771 and not the relation 3825989 : it looks like a bug

2. too much elements, a relation is in the result when not in the area :

I have another more complex result : the same query for another country (replace "Marshall Islands" with "Oman" in the above query). This country has a main area and 2 exclaves, see https://www.openstreetmap.org/relation/305138#map=6/21.739/56.019. The final result shows all the relations inside this area (in particular the complex relation https://www.openstreetmap.org/relation/3781315 = good news) but also a relation which is clearly outside the area : https://www.openstreetmap.org/relation/12905765#map=6/21.739/56.019

So sometimes "map_to_area" gives not enough datas and sometimes too much datas : I hope you will find what is going on because this statement is (will be) very useful.

Best regards.

[drolbr]

There is some tweaking necessary here: the area operator so far does not find ways that are exclusively on the boundary and have no inner point. The rationale behind this is that usually one does not want to catch adjacent administrative units that share a common border with the area in question.

It could be decided that a way or relation exclusively on the boundary is indeed included, but I do not ad hoc overlook whether this has unintended consequences.

[MALKARAJ]

Hi is there any solution for getting the missing data without direct querying the osmid

[drolbr]

You can use this query as a workaroud:

[out:csv(::id,admin_level,name,"name:en",wikidata,wikipedia)];

rel["name:en"="Marshall Islands"]->.base;
way(r.base)->.border;
rel(bw.border)[admin_level]->.all;
( way(r.all); - .border; )->.nonborder;
( .base map_to_area;
  rel[admin_level](area);
  ( .all; - rel.all(bw.nonborder); ); );
out;

This collects in addition to the relations found by the area mechanism also all relations whose boundary lies fully on the boundary of the starting relations.

[Mahabarata]

Thanks for your workaround.

If you add in your query, in the csv list, the special field "::type", you will see that in the result there is something which is not a "relation" but an "area".

How to remove it ?

[Mahabarata]

I found the answer: just a parenthesis not at the good place.

[out:csv(::type,::id,admin_level,name,"name:en",wikidata,wikipedia)];

rel["name:en"="Marshall Islands"]->.base;
way(r.base)->.border;
rel(bw.border)[admin_level]->.all;
( way(r.all); - .border; )->.nonborder;
.base map_to_area;
( rel[admin_level](area);
  ( .all; - rel.all(bw.nonborder); ); );
out;

So it solved the first issue when there are ways that are exclusively on the boundary and have no inner point.

For the second issue I also solved it : there were 2 different ways for the boundary of the relation 305138 and the boundary of the relation 12905765 and the second one was not on the first one but offset at a node. I removed the redundant way.

So this issue is completed, thanks again.