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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev