[mkgmap-dev] Test cases for possible is-in-hook

Fri Jan 3 10:37:22 GMT 2020

Hi all

In a recent svn commit message, Gerd wrote:
> check both lines and polygons with the same method
> As expected performance is poor when compared to ResidentialHook 

If some users were happy with the approximations used by the
--residential-hook implementation, I see no reason why the same
algorithm shouldn't be invoked under the control of the accuracy
parameter, eg:

> highway=path & is_in(landuse, residential, approx) {...} [...]

Going back to the test cases, just considering lines and their
relationship to polygons and exact/maximum precision, possibilities
are:

1/ all of the line is outside the polygon
2/ some of the line is outside and the rest touches or runs along the
polygon edge
3/ all of the line runs along the polygon edge
4/ some of the line is inside and the rest touches or runs along.
5/ all of the line is inside the polygon
6/ some is inside and some outside the polygon. Obviously some point is
on the polygon edge but we don't care if runs along the edge.

If an apex of the line touches the edge of the polygon (from either
inside or outside) or an apex of the polygon touches the line (again
from either side) then this should be considered an 'on' point

The questions that it seems meaningful to ask (via the accuracy parameter) are: 

a) all-in, ie. 5/
b) all-in-or-on, ie. 3/ or 4/ or 5/
c) all-on, ie 3/
d) any-in, ie 4/ or 5/ or 6/

For some of these cases the inverse is meaningful and useful:
> barrier=wall & is_in(building, castle, all-on)=false [0x17]
ie: don't render a wall that follows the edge of a castle

@all, please say if you see the need for other tests and which of 1/ ..
6/ they should return 'true' for.

It might be too complex to spot the all the cases enumerate earlier, so
this is not a promise of the final functionality.

Also, I'm not saying these should be the final keywords - suggestions
welcome.

Ticker

On Sat, 2019-12-21 at 09:02 +0000, Gerd Petermann wrote:
> Hi all,
> 
> this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-re
> vert-changes-from-r4397-is-in-landuse-option-tp5953750p5954041.html
> Attached is a new file which contains additional ways w28 .. w30 and
> w26 was changed from expected="?" to "in".
> The new ways are all very close to the residential polygon(s), but
> completely outside. 
> I think w26 and w30 show very common cases in OSM. Some mappers
> prefer to "glue" landuse polygons to highways, others don't. There
> are probably good reasons for both methods. Because of the poor
> precision the current code in mkgmap adds mkgmap:residential to both
> of them. See 
> http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html
> where Carlos stated that this would be welcomed (at least if the ways
> were e.g. highway=secondary instead of footway).
> If I change the code to be a lot more precise w30 would not be
> tagged. 
> On the other hand, if you ask for landuse=cemetery you probably don't
> want to change a cycleway next to it.
> Any ideas how to handle this dilemma? 
> 
> Gerd
> 
> P.S. In my hometown the cemetery expanded during the years and it now
> stretches across a residential road "Lehmkuhlenweg".  
> See https://www.openstreetmap.org/way/11760536
> I think in reality the cemetery is split into two parts, there are
> gates on the footways and barrier=fence or barrier=hedges along the
> road, but nobody mapped them until now.
> 
> 
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev