[mkgmap-dev] tile takes very long time to generate

Wed Mar 31 10:39:39 BST 2021

Hi Ticker,

reg. polish input: There was code based on the documentation and I removed it again. Don't remember why, see changes for r4269 and r4272 and
http://gis.19327.n8.nabble.com/Artifacts-in-final-map-MP-gt-IMG-conversion-tc5932812.html

The current code is really too complex. A lot of the code exists for reporting purposes only. Another big portion is for the handling of incomplete data.
There are probably hundreds of possible error cases with MPs. One of my goals is to find out which ones are tolerated by the current code and why they are tolerated.

If nobody offers an approach regarding unit tests we may try to simply write a 2nd implementation for MultipolygonRelation and use an option to switch between them.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Mittwoch, 31. März 2021 11:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] tile takes very long time to generate

Hi Gerd

Looking at the Polish format (cGPSmapper-UsrMan-v02.4.pdf), my
understanding is that a polygon definition with multiple Data#
statements at the same level defines a single outer with multiple
inners (Page 20 and 74/5).

Touching inner or outer rings is a slightly different problem and, I
think, the current code has made all its choices about this before the
complexity of geometry determination.

I wasn't suggesting stopping on errors, but if there are only 2 way
elements ending at a Coord, and one is explicitly marked "inner" and
the other "outer" then I think this can be errored and chucked.

Ticker

On Wed, 2021-03-31 at 07:57 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't know what data we see when MultipolygonRelation is used with
> polish input, but I am sure that there is no info about roles.
>
> I also thought about using the info about the area size as a quick
> indicator before doing complex tests.
>
> The missing unit tests are my real problem. I've not (yet) found a
> good way to test the result. I'd like to have a test that allows to
> rotate or reverse rings so that we find errors with handling of the
> closing node.
>
> I think we need the complex and somehow tolerant tests for the
> boundary calculations, we cannot simply stop on error. I know that
> some admin boundaries have very special cases (France), they are not
> exactly correct reg. the rules for touching outer rings.
>
>
> So, I started to use already tested code where possible, e.g.
> IsInUtil. See attached patch. Run times seem similar to the existing
> code in trunk.
> Just experimental so far, but at least a lot less code...
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 30. März 2021 15:17
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
>
> Hi Gerd
>
> I'm revising my opinion about considering the geometry to determine
> inner and outer.  All the different BitSets, containsMatrix etc logic
> is too complex, and if it then conflicts with the explicit definition
> of the MP it just gets worse.
>
> I'd simpify it along these lines:
>
>  split the polygon/joinedWay list:
>    error: the explicit conflicting inner/outer
>    inners: at least one inner element
>    outers: all the rest
>
>  for each inner
>    find a larger_area outer that contains a part of it
>      add to the outer.listOfInners
>      error if more than one
>
>  for each outer
>    cut out listOfInners
>    apply tags
>    output to the wayMap
>
> This copes correctly with outer with inner hole that
> contains another outer. If, in the above logic, more than one larger
> outer is found, then choosing the smallest would allow this nesting
> to
> any level.
>
> Ticker
>
> On Thu, 2021-03-18 at 10:21 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > I still struggle with the unit test because it's hard to say what
> > we
> > want to get in special cases.
> > The current code doesn't really work in the way that I expected. I
> > always thought that roles like "inner" and "outer" are completely
> > ignored and that mkgmap calculates and uses the correct roles. This
> > is only partly true. See attached file with MP were a forest
> > contains
> > a lake that contains a forest.
> > For a nested polygon where the innermost ring has wrong role
> > "inner"
> > this doesn't work as expected. The forest  in the lake is ignored.
> > With the correct role "outer" it is not ignored. No idea if this is
> > intended or an error. Fortunately nested MP are very rare.
> >
> > Gerd
>
> _______________________________________________
> 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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev