Differences in what is considered 'inside'

[DaveF63]

Hi Unsure if this is an anomaly, or I'm not understanding the code

I'm trying to return all golf=hole ways which are in reverse direction to the direction of play.

Initially I get the first node of the hole ways, then get any golf=greens which have those nodes inside them. Those greens are converted to areas to search for thegolf=hole ways within them.

I'm expecting the routine to display a golf=hole way for all the returned golf=green polygons

The problem: is_in appears to accept first node of the hole ways which are attached to the perimeter of golf=green polygons. However the (area) search requires them to be inside.

Is there a reason for this difference or am I missing the point? Is there a better way for me to perform this action?

https://overpass-turbo.eu/s/1koW

[bbox:{{bbox}}];
way[golf=hole];
node(w:1);
is_in;
way(pivot)[golf=green]->.Green;
.Green map_to_area;
way[golf=hole](area);
out geom;
.Green out geom;

[drolbr]

Thank you for raising the question.

The rationale behind the semantics are the most common use cases for each:

1. if one uses is_in to figure out the country one is in then the expected behaviour on a boundary, in particular at a tripoint, is to return all the countries.
2. if one uses (area) to get a excerpt from the map then the expected behaviour is to not include streets outside that area that end on the boundary and also not to include neighbouring administrative units that happen to share part of their boundary with the boundary used.

Technically, the two operators behave symmetrically as follows: is_in anyway finds only nodes as of now, and (area) does return nodes on the boundary. So

[bbox:{{bbox}}];
way[golf=hole];
node(w:1);
is_in;
way(pivot)[golf=green]->.Green;
.Green map_to_area;
node(area);
way[golf=hole](bn);
out geom;
.Green out geom;

does find all the ways of interest.

There are plans underway to completely replace the remaining areas with relations and to keep area as synonym for closed ways and relations only. I'm classifying this as enhancement because in the course of that implementation it does make sense to revisit whether a parameter to configure the behaviour of ways on the boundary makes sense.