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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev