[mkgmap-dev] Gaps in surfaces

Wed Oct 4 09:16:57 BST 2023

Hi Ticker,

I've uploaded the test case: https://files.mkgmap.org.uk/detail/564
I had to modify the data a bit since the default style doesn't render natural=heath

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Montag, 2. Oktober 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 with such an extreme delta is used (after converting to double) in Area.subtract() and the returned coord is converted back but get's the other extreme. In the end, only the 24 bit value is written to the map, and that causes the gap.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 2. Oktober 2023 15:55
An: Development 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 their use by getAlternativePositions,
are just used to get back to the highPrec coord value.

The deltas are stored as byte, so the value of +32 causes no arithmetic problems generally.

getAlternativePositions(), however, should handle any complications with the +32, but it looks
like it mostly does, bumping up or down the 24bit coord if the abs(deltas) are > 16. It it
really possible that modLxxDelta can overflow a byte here?

Haven't looked at LineClipperTest yet.

Ticker

On Fri, 2023-09-29 at 06:57 +0000, Gerd Petermann wrote:
> Hi all,
>
> I've found out that this problem is caused by a flaw in the "high precision" code. Under
> special conditions, two points with almost identical coordinates are internally represented
> with very different values. There is a possible overflow in the delta values, the value +32
> should not occur as it cannot be represented with 6 bits, but the calculations produce this
> value.
> I think I have an ugly fix for this but the resulting map still shows (smaller) gaps and a
> unit test needs corrections, so there is more to do.
> Attached is a patch that checks for this overflow. Work in progress and maybe causes trouble
> in other areas, e.g. in South America where we have negative lat/lon values.
>
> @Ticker: The unit test für LineClipperTest fails. I am not sure if only the test has to be
> changed (how) or if the code in LineClipper can be improved. I seem to remember that you
> suggested to use
> the code in ShapeSplitter instead.
>

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev