Hi Gerd Sorry - bit hasty in my reply I need to look at the other places that use DELTA_SHIFT and check their arithmetic/rounding etc is consistent with the corrected highPrecCoord and uniform in rounding behaviour. Ticker On Fri, 2023-10-06 at 16:15 +0100, Ticker Berkin wrote:
Hi Gerd
My change to toMapUnit should be almost undetectable. Imagining mapUnits [x] as degrees over the real range -2.5 .. +2.5, the original implementation resulted in:
-2.5 < [-2] <= -1.5 < [-1] <= -0.5 < [0] < -0.5 <= [1] < +1.5 <= [2] < +2.5
I've changed it to give:
-2.5 <= [-2] < -1.5 <- [-1] < -0.5 <= [0] < -0.5 <= [1] < +1.5 <= [2] < +2.5
The change to highPrecCoord is so that 64 highPrecCoords are exactly within the appropriate mapUnit, with deltas of -31..+32 according to the existing delta calculations.
Ticker
On Fri, 2023-10-06 at 14:34 +0000, Gerd Petermann wrote:
Hi Ticker,
your patch rounds the problematic point to a different position, the same that is assigned to the new Coord instance that is derived from the cutOutInnerPolygons() method which involves singularAreaToPoints() and thus another place where rounding happens: int latHp = (int)Math.round(res[1] * (1<<Coord.DELTA_SHIFT)); int lonHp = (int)Math.round(res[0] * (1<<Coord.DELTA_SHIFT));
I think we have to check all nodes which are part of an inner and change position because of your different rounding method, right? I wouldn't be surprised to find cases where a gap occurs with (just) your patch. I'll try to find an example... If I can't we may just use your patch, although it's much harder to understand compared to the original code.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev