[mkgmap-dev] Work on is_in branch

Fri Feb 21 08:20:42 GMT 2020

Hi Ticker,

I use GpxCreator class for debugging. It produces output pairs of files with garmin 24 bit precision as well as the highprec 30 bits. Helps a lot to understand how OSM values are rounded and were calculated points are placed when you load them in JOSM.

Gerd

________________________________________
Von: Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Donnerstag, 20. Februar 2020 18:37
An: Gerd Petermann; Development list for mkgmap
Betreff: Re: AW: [mkgmap-dev] Work on is_in branch

Hi Gerd

Attached is a quick patch that cause b14 to give the correct answer for
the 'any' method and hence pass the test; merge the 2 polygons and then
it processes 1 outer, 1 hole with the expected results

When my mind is up to it, I'll try and work out what happens during the
isLineInShape processing. The hole after merging appears to retain the
same upper and lower mid-points from the cutting and matches the line,
with the values as output like (not sure what the precision is here):

line [2492250/449714, 2492167/450038, 2492073/449970, 2492155/449646,
2492250/449714]
ie the inner b14

polygon [2491978/449872, 2492086/449391, 2492384/449581,
2492319/449872, 2492209/449872, 2492250/449714, 2492155/449646,
2492097/449872, 2491978/449872]
ie 1/2 of the MP from cutting. this gives IN|ON|OUT, should be ON|OUT

hole [2492073/449970, 2492167/450038, 2492209/449872, 2492250/449714,
2492155/449646, 2492097/449872, 2492073/449970]
after the java2d merging - this gives ON

Ticker

On Thu, 2020-02-20 at 17:04 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> patch is commited. It is a bit difficult for me because you change a
> lot of things and the unit test fails.
> I just want to make sure that we have something testable in the end.
> It is already difficult enough to understand what is documented.
>
> I think the tests are not always working because the result of
> Coord.makeBetweenPoint is rounded. That means a point calculated with
> it is typically not ON the line between the given points. A possible
> solution would be to change all the code in IsInUtil to use double
> values and rewrite e.g. makeBetweenPoint and the other used methods
> to keep the double precision. Still, it might fail when java area
> code comes in because that always uses a flat earth calculation.
> When I understood that I felt indeed a bit relunctant.
>
> 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, 20. Februar 2020 17:45
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> I don't think the test data 'expected' values are wrong, it is just
> that they are more specific than the 'method' mechanism allows to be
> differentiated; eg a polygon can only be tested for ALL in or ANY in.
>
> At the moment I feel you have a reluctance about the whole concept of
> the methods. Once the principle is accepted, I'll go through the test
> data and add, as another tag, the list of methods that should match
> the
> element, then change the test driver to check that these match and
> the
> other applicable methods don't.
>
> Reg. b14: It isn't the stop-early code that causes the problems,
> isLineInShape is not giving the correct answer for a simple polygon
> produced by the MP cutter.
>
> It would be quite easy to introduce some POLYGON 'on' methods, that
> match the outer, inner or either edge of a polygon, but maybe this
> could wait until there is a call for it.
>
> Next mail:
> I'll change the sentence as you suggest.
>
> Please can you commit the patch as it stands; it has a lot of good
> stuff in it. Then I can do the IsInUtilTest and test data changes as
> the next stage. It's also handy to see how the Style Manual looks
> after
> each build into the download area, because I don't know how to
> generate
> it and am just guessing at the formatting.
>
> Thank you
> Ticker