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
>
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] <
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
Hi Gerd
I've now looked at your example (mp-gap2.osm). With my toMapUnit/toHighPrec
patch the problem
almost disappears. I don't see any significant difference when I also apply
your mp-cut-coord-
pool.patch.
I can't see a way of fixing these gaps/overlaps without disabling a lot of
filter poi
