Hi Gerd niceSplitShift: OK. I presume that, for the multipolygon logic, it doesn't matter that the area splitting division line isn't accurately representable at lower resolutions. missingOuter: I've never quite followed this part of MP processing but a specific error relating to the input geometry, rather then "Internal Error', must be much better. checkAllOn: I think I'm missing something here and need to look at the code more carefully. Will do this in a few days. Happy Christmas Ticker On Tue, 2024-12-24 at 10:00 +0000, Gerd Petermann wrote:
Hi Ticker,
sorry for the late response. I think the main problem is the value for niceSplitShift. I see much better results when I change that to 0 so that partitions are divided into equal halves. I've also learned that the reported internal error is more often caused by invalid multipolygons where a ring with role inner is outside of the bbox of the outer ring. Try e.g. https://files.mkgmap.org.uk/detail/566
I've attached a patch to address these two problems. One other problem that I noticed is in method IsInUtil.checkAllOn() Coord pTest = p1.destOnRhumbLine(EPS_OFF, p1.bearingTo(p2));
I noticed cases where this code calculates a point which is not on the line between p1 and p2, e.g. if the distance between these two points is smaller than EPS_OFF. I introduced this line with r4499 which refers to your patch isPointInShape_v3.patch. No idea why, I can't find the changes in that patch. Maybe I look at wrong file.
The partitioning is really a performance boost with very complex MPs like that for lake Huron (relation 1205151). I see 10 secs instead of +130 secs with partitioning. On the other hand it is more likely to hit edge cases where small fragments of touching inner rings are reported as possibly wrong nested inners.
Gerd