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

Mon Mar 15 08:50:30 GMT 2021

Hi Gerd

Although it feels correct that the roles should be respected and used
to avoid complex logic to work out the geometry, and blank role should
be assumed outer, given it needs to work out which polygons to cut out
from others, I agree with you and they should just act as a validation.

I started looking in detail at the initial stages of MP processing at
the end of last week and have re-written code to do the joining into
polygons and lines. One thing I've done is added inner/outer counts to
JoinedWay so conflict can be recognised (either in the free-standing
polygon or with respect to the geometry of other polygons).

I'll send you this in a while and you might consider some of the ideas
worthwhile. At the moment is handles everything in the GB map except
double-joined polygons and some strange boundaries (11 problems in all)

Ticker

On Sun, 2021-03-14 at 08:47 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> the handling of the inner/outer role is indeed strange. The program
> calculates the "real" roles first, based on geometry. Later it checks
> if the given roles from the relation and may ignore the MP if no way
> has an empty role or role outer. This test should be done first or
> not at all.
> 
> I think it is a good idea to calculate the roles based on geometry,
> for empty roles we need the code for this calculation anyway. I just
> think that mkgmap shouldn't care too much about invalid geometries
> when data is complete.
> I have to think again about those cases where data is not complete.
> Even with splitter and --keep-complete this can happen, e.g. when the
> input for splitter already contains incomplete relations.
> 
> Maybe mkgmap can simply ignore incomplete MP after logging a warning.
> 
> Gerd
> 
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Samstag, 13. März 2021 12:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
> 
> Hi Gerd
> 
> I think the extra testing should be removed and the logic should work
> on the assumption of correct data; just emitting warning/errors when
> problems are found during the normal processing.
> 
> It also has extra complexity due to early versions of the splitter
> not
> keeping relations/polygons complete. Presumably this can be
> simplified
> now.
> 
> role=inner/outer handling is strange, it looks like it totally
> ignores
> it! Going with "assuming correct data", conflicting "inner" and
> "outer"
> in a JoinedWay should be flagged, otherwise any "inner" or "outer"
> should be believed, with all null being considered "outer".
> 
> Ticker
> 
> 
> On Sat, 2021-03-13 at 08:32 +0000, Gerd Petermann wrote:
> > Hi all,
> > 
> > most of the time that is needed to process complex multipolygons
> > (MP)
> > is spent in compex tests which try to detect invalid geometries
> > like
> > "inner" ring is not inside outer or overlapping /crossing rings. I
> > wonder if it really makes sense to perform those tests in mkgmap.
> > In
> > JOSM, the strategy is like this:
> > The renderer is optimistic and assumes that the geometry is
> > correct,
> > for invalid geometries "garbage in -> garbage out" is used. The
> > validator performs a lot more tests and should find all the special
> > cases mkgmap is looking for. This test is slow but still much
> > faster
> > than that in mkgmap (maybe 30 secs in JOSM, many minutes in
> > mkgmap).
> > If mkgmap finds invalid geometries the behaviour is still rather
> > unpredictable. I've used JOSM to create some test cases with
> > "inner"
> > overlapping "outer" and sometimes the inner is completely ignores,
> > sometimes not. So, I really wonder what all the complex code is
> > doing.
> > 
> > I've attached my test file
> > I am not sure if I should try to improve the test code
> > 1) to be faster or
> > 2) to be more predictable or
> > 3) both 1+2 or
> > 4) if I should just remove all code that isn't needed to produce
> > good
> > results with correct data
> > 
> > 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