[mkgmap-dev] Work on is_in branch

Fri Mar 6 08:16:14 GMT 2020

Hi Ticker,

My concerns regarding a merge to trunk are resolved. Anything else you want to change?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at 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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev