[mkgmap-dev] Gaps in surfaces

Fri Oct 6 16:22:38 BST 2023

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 at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev