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

Mon Jan 6 11:21:27 GMT 2020

Hi all,

sorry for the slow progress. I've a bad cold since Christmas and I amstruggling with rounding errors and edge cases. I came to the conclusion that the rounding errors (esp. those from 32 bit OSM precision to mkgmap 30 bit "high precision" ) make it impossible to get correct resuls whenever a node is very close to a line segment. When JOSM shows this node being outside or on boundary of a given polygon, the rounding may place it inside (or vice versa).
You can think of a halo of maybe 5 cm around the objects displayed in OSM where you cannot trust the results.

The attached file contains an example. I've created building b18 in JOSM by drawing a building next to the residential area. Then I used N (Move node onto way) with the nodes next to the area. Finally I've unglued the building again and removed the nodes from the residential area. Result in JOSM is that one segment of b18 is exactly on the boundary of the residential area. Now, after the rounding, the lower left corner of the building is moved a tiny bit up and the the lower right corner is moved a tiny bit down relative to the residential area.  As a result, the standard insideness calculations find a crossing segment and thus calculate a 6 in Tickers list. Results can change when you select both ways and move them to a different position.
Fortunately this doesn't happen often in real OSM data, typically objects which are that close to each other share nodes, but the exceptions are very often along a highway.
Anyway, I've decided to ignore the wrong results created by the rounding for now...

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Samstag, 4. Januar 2020 12:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Test cases for possible is-in-hook

Hi Jan

OK, but Outside needs to be expressed in the inverse, ie

e) any-in-or-on  >  3/ 4/ 5/ 6/

and then tested as ... is_in(tag,val,any-in-or-on)=false ...

because the logic will look for all correctly tagged polygons nearby
and then check each in turn to see if it matches the accuracy
requirements and stop with 'true' if it does, returning 'false' if none
match. So, if there were two matching areas, the line could be outside
one and inside the other, and 'outside' would return true.

The cases 1/ to 6/ would be more logically expressed with 3 flags:
  IN, ON, OUT
set as the algorithm examines the relationship of the line segments
with the polygon segments, then we have:

a) all-in            IN and not (ON or OUT)
   Jan's alternative IN and not OUT
b) all-in-or-on      (IN or ON) and not OUT
c) all-on            ON and not (OUT or IN)
d) any-in            IN
e) any-in-or-on      IN or ON

Ticker

On Fri, 2020-01-03 at 23:49 +0100, jan meisters wrote:
> Hi all,
>
> I would define the 6 cases in Tickers given (with the explained
> handling of apexes) as followed:
>
> a) all-in                     >       4/ 5/
> b) all-in-or-on               >       3/ 4/ 5/
> c) all-on                     >       3/
> d) any-in                     >       4/ 5/ 6/
> Outside                       >       1/ 2/
>
> These options are impressively complex, I can´t imagine any further
> yet.
>
> Jan
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: is-in-hook-samples-v3.osm
Type: application/octet-stream
Size: 40893 bytes
Desc: is-in-hook-samples-v3.osm
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200106/f28a7010/attachment-0001.obj>