Hi Ticker, My concerns regarding a merge to trunk are resolved. Anything else you want to change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Dienstag, 3. März 2020 15:22 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Ticker, nice :) Committed with r4461, with small changes. This even allows to change the test case for lamp4 from expected="?" to expected="2" (ON). reg. the distance calculations: I don't remember the details and maybe all is wrong. See svn log for r3333 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3333 and search the archives for "Great Britain National Grid". The math behind projections and distance formulas is too complex for me. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 3. März 2020 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Patch attached: - inherits your is_in-function_v14.patch - adds Math.round to Coord.makeBetweenPoint(); Is this how you indented? - removes IsInUtil.insidePolygon() and changes callers to use isPointInShape() - adds ON tolerance to isPointInShape() - I couldn't work out how to do this with the winding algo, so changed it to crossing-point, which is fine for mkgmap polygons. - add some more tolerances to isLineInShape - isLineInShape had comment: // it is unlikely but not impossible that pTest is on boundary :( and it returned the wrong result if it was. This contributed to the difficulties with b14 (and b19). I've fixed it and, I think, improved and simplified the running status setting - fix spelling of rhumLine to rhumbLine There are still a couple of places that have complicated distance calculation and point insertion using, bearings, rhumbline, meter conversion but I don't think it is worth re-implementing them for this. I'm slightly surprised how much use there is of bearing/rhumbLine/Mercator projection calculations. I think real distance/metre calcs should be "great circle" and internal poly/line chopping, testing etc should be high-precision polar coords. Ticker On Thu, 2020-02-27 at 19:36 +0000, Gerd Petermann wrote:
Hi Ticker,
if you see a way to change the algo just do it. I've just noticed that I forgot to commit a change in Coord.makeBetweenPoint(). This routine should use Math.round. Will reduce the error by 50%, right?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 27. Februar 2020 20:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Looking at the distance calculations to compare with EPS (ie very small), wouldn't it be much simpler and clearer just to calculate it as highPrecisionSquared units, not bothering with degrees/radians, rhumb -line, metre conversion etc. Then EPS would be 4.
Then, considering IsInUtil.insidePolgon and can it be changed to have some tolerance and maybe changing the interface to return IN/ON/OUT, it looks like it will stop, returning onBoundary, if there is a polygon segment that 'aims at' the point.
Ticker
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev