[mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.

Thu Apr 1 16:26:40 BST 2021

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 then I agree, each inner needs to be tested against
all the outers (but not against each other). isPointInShape will be a
lot quicker than isLineInShape or the existing trunk logic.

Ticker

On Thu, 2021-04-01 at 14:49 +0000, Gerd Petermann wrote:
> 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 &Conquer 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 in shape" test requires lots of time for such a
> complex outer ring, and a single test will not find intersections.
> 
> Have to think about the data structures but I am sure this will be
> much faster for most of the really complex MP.
> 
> Gerd
> 
> 
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 1. April 2021 14:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> to do geometry calculations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
> 
> 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 suggested earlier.
> 
> The error reporting is not good - it can generate many lines in the
> log. An idea would be to have:
>   Element lists for each way-like problem.
>   Counts or flags for other problems.
>   etc
> and, for each problem detected, add all the ways in JoinedWays,
> increase appropriate count, set the flag etc. At the end, if any of
> these are populated, output the Relation and then, if full
> diagnostics,
> each populated problem type followed by lists of wayIds on same line
> etc.
> 
> Ticker
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev