logo separator

[mkgmap-dev] [PATCH v1] Performance improvement by removing unused elements before the style processing

From WanMil wmgcnfg at web.de on Tue Jan 3 19:33:26 GMT 2012

Hi Greg, hi Gerd,

yes, it would be great if the splitter throws those elements away. But 
that's a discussion that pops up every few months. Filtering out those 
elements seems to be difficult and makes the splitter *much* slower. As 
far as I understood you need (at least?) two passes of the input file 
for that. Splitter would have to detect all ways that intersect the 
bounding box and all ways and nodes that are part of a multipolygon 
intersecting the bounding box. That also means that splitter has to 
implement an multipolygon handling.

Routing and multipolygons require the splitter overlap functionality. By 
increasing the overlap parameter many more multipolygons are complete or 
in such a status that the MP algorithm of mkgmap can do its best to 
guess how the holes must be completed.

The patch also removes all ways and nodes without any tag. They exist 
because mkgmap only loads tags that are referenced by the style. But 
mkgmap cannot throw them away during loading because they might be 
referenced by multipolygons.

The patch has bug: Ways and nodes without any tag must not be thrown 
away if they are referenced by a relation. The relation might be used to 
tag the ways and nodes (e.g. a bus route). I will post an update later on.

WanMil


> Hi,
>
> this is another performance improvement:
>
> Usually the mkgmap input tiles are larger than the processed bounding
> box (splitter parameter overlap). So there are much many elements which
> are processed but thrown away at a late step in mkgmap.
>
> The patch tries to remove them much earlier before the style files are
> processed and before the LocationHook starts (which ignores them but
> that must also be calculated).
>
> The patch contains one drawback:
> Ways which have all its points outside the bounding box of the tile but
> which cross the tile are also removed. If that's a point the patch must
> be improved.
>
> Have fun!
> WanMil
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




More information about the mkgmap-dev mailing list