Re: [mkgmap-dev] Gaps in surfaces

t for mkgmap' Betreff: Re: [mkgmap-dev] Gaps in surfaces Hello Gerd, here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I understand that it is necessary to make rounding. If a point of two surfaces is equal in OSM, the point should also be equal in Garmin. Thank you! Be

Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd I've looked through all the places I could find that took [highPrec]coord vals, manipulated them and then converted back and they all seem safe with my patch. There might be slight differences where, using Java2DConverter or similar, a calculated value converts to a different/adjacent h

Re: [mkgmap-dev] Gaps in surfaces

eff: Re: [mkgmap-dev] Gaps in surfaces 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

Re: [mkgmap-dev] Gaps in surfaces

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 >

Re: [mkgmap-dev] Gaps in surfaces

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] <

Re: [mkgmap-dev] Gaps in surfaces

latHp = (int)Math.round(res[1] * (1< im Auftrag von Ticker Berkin Gesendet: Freitag, 6. Oktober 2023 16:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Gaps in surfaces Hi Gerd I've now looked at your example (mp-gap2.osm). With my toMapUnit/toHighPrec patch the proble

Re: [mkgmap-dev] Gaps in surfaces

be the attached patch which > > makes use of the > > coord pool. > > No idea which one has more effects on performance. > > > > Gerd > > > > > > > > > > > > Von: mkgmap-dev im Auftrag v

Re: [mkgmap-dev] Gaps in surfaces

the attached patch which > makes use of the > coord pool. > No idea which one has more effects on performance. > > Gerd > > > > > > Von: mkgmap-dev im Auftrag von > Ticker Berkin > > Gesendet: Mittwoch,

Re: [mkgmap-dev] Gaps in surfaces

ch, 4. Oktober 2023 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Gaps in surfaces Hi Gerd I've been thinking about how to stop the small ranges of decimal degrees from generating MapUnit/delta=+32 and MapUnit+1/delta=-32. Without changing the MapUnit value, but truncating the hig

Re: [mkgmap-dev] Gaps in surfaces

ault style doesn't render > natural=heath > > Gerd > > > Von: mkgmap-dev im Auftrag von Gerd > Petermann > > Gesendet: Montag, 2. Oktober 2023 16:58 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Gaps in surfaces > > Hi Ticker,

Re: [mkgmap-dev] Gaps in surfaces

er 2023 16:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Gaps in surfaces Hi Ticker, the word overflow might be confusing. The problem is that we want to use only 6 bits for the delta, but we store values from -32 .. 32. The special case with Michael example is that one coord wi

Re: [mkgmap-dev] Gaps in surfaces

pment list for mkgmap Betreff: Re: [mkgmap-dev] Gaps in surfaces Hi Gerd Considering no_hp-overflow_alpha.patch: It seems wrong to change a 24bit coordinate. Utils.toMapUnit() is well defined to do the expected rounding with the conversion. The actual deltas are local to Coord.java and, apart from

Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd Considering no_hp-overflow_alpha.patch: It seems wrong to change a 24bit coordinate. Utils.toMapUnit() is well defined to do the expected rounding with the conversion. The actual deltas are local to Coord.java and, apart from their use by getAlternativePositions, are just used to get b

Re: [mkgmap-dev] Gaps in surfaces

be fixed by avoiding these cuts or by modifying the inner rings. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Freitag, 29. September 2023 11:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Gaps in surfaces Hi I was

Re: [mkgmap-dev] Gaps in surfaces

plitter instead. > > > Von: mkgmap-dev im Auftrag von Gerd > Petermann > > Gesendet: Dienstag, 26. September 2023 19:58 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Gaps in surfaces > > Hi Michael, > >

Re: [mkgmap-dev] Gaps in surfaces

ou suggested to use the code in ShapeSplitter instead. Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Dienstag, 26. September 2023 19:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Gaps in surfaces Hi Michael, okay, I can reproduce

Re: [mkgmap-dev] Gaps in surfaces

, 26. September 2023 19:44 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] Gaps in surfaces Hello Gerd, here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I understand that it is necessary to make rounding. If a point of two surfaces is equal in OSM,

Re: [mkgmap-dev] Gaps in surfaces

Hello Gerd, here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I understand that it is necessary to make rounding. If a point of two surfaces is equal in OSM, the point should also be equal in Garmin. Thank you! Best regards, Michael _

Re: [mkgmap-dev] Gaps in surfaces

: 'Development list for mkgmap' Betreff: [mkgmap-dev] Gaps in surfaces Hello, in some areas, gaps may appear (see attachment). In OSM, however, the surfaces are connected and the nodes have the same coordinates. There should be no rounding errors. It will therefore be a bug in mkgmap. I ask for