Hi Ticker,
I use JOSM to display the relation and I can see the numbers when debugging in
Eclipse.
I'd prefer to have a stable and fast algo that works without looking at the
roles, but we can always add rather simple code to handle a single outer ring
without checking anything.
Gerd
Hi Gerd
I can't get to see this relation - it times out.
If element roles can be trusted (either OSM or Polish with some
appropriate rule) and there is only 1 outer, then no need to test
anything - all the inners can be assigned to this and proceed onto the
cutting stage.
If multiple outers
Hi Ticker,
I still see no way how any of this will help reg. throughput. I think we need
something like the BoundaryUtil.rasterArea() method as a Divide
approach, at least for monster relations like r9488835.
The outer ring has +413.000 points and there are +15.000 rings. Even a single
"point
Hi Gerd
2 more thoughts:
For elements from Polish input, set a distinct role. This can be
spotted early and either the order rule or direction rule can be
applied (they are closed, so the area/direction can be calculated
immediately). This then allowed OSM data with a blank role to be
handled as
I meant intersecting polygons
Ticker
On Thu, 2021-04-01 at 12:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I agree that calcContains should be changed as you suggest.
>
> My view otherwise is that the code should be as simple as possible
> for
> "correct" cases and not go to any trouble to
Hi Gerd
I agree that calcContains should be changed as you suggest.
My view otherwise is that the code should be as simple as possible for
"correct" cases and not go to any trouble to detect overlapping
polygons in this phase, but just allocate them as [outer {inner}]+ and,
if the cutting logic
Hi Ticker,
I think the big question is what the code is expected to do with overlapping
polygons. The code in trunk may or may not cut out an inner ring that overlaps
the outer. If I got that right it was intended to ignore all rings which are
overlapping, but I showed that this doesn't always
Hi Ticker,
to be more prezise: Looking at the code in runIntersectionCheck() it may change
the Bitset unfinishedPolys. Up to now I did not find a case where this happens,
so I am tempted to remove the code, but I'd feel better if I would understand
why it was coded before removing it.
Gerd
Hi Ticker,
yes, that's what I plan to do. Right now I try to understand what is done with
the data in collection intersectingPolygons.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 1. April 2021 09:25
An:
Hi Gerd
Wouldn't it be more efficient to choose a point within a each polygon
and then use IsInUtils.isPointInShape and the relative areas to test if
this polygon is in others. The point could be the centre of the
polygon, after checking isPointInShape == IN on itself, and, if not,
make do with
10 matches
Mail list logo