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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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