logo separator

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

From Ticker Berkin rwb-mkgmap at jagit.co.uk on Sat Mar 13 11:21:09 GMT 2021

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



More information about the mkgmap-dev mailing list