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 <[email protected]> im Auftrag von Ticker Berkin <[email protected]> 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 [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
