[mkgmap-dev] Gaps in surfaces
From Ticker Berkin rwb-mkgmap at jagit.co.uk on Fri Oct 6 16:15:20 BST 2023
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
- Previous message: [mkgmap-dev] Gaps in surfaces
- Next message: [mkgmap-dev] Gaps in surfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list