[mkgmap-dev] [PATCH v2] Reduce number of cuts in multipolygon processing

Mon Mar 1 22:28:19 GMT 2010

On 01.03.2010 23:20, WanMil wrote:
>> BTW, after using this option a bit more, I could see some general
>> improvements, meaning less cuts in polygons overall.
>> Speed improvements for compiling Europe completly, were modest but
>> noticeable. (around 5min down, for ~2hrs total)
>
> Felix,
>
> did you compile the Europe map with generate-sea=multipolygon?
> My speed improvements of 75% were generated with this option. I also 
> think that this is the best of possible speed improvement with this 
> patch ;-)
>
> It is important for me that no major problems are observed with it. I 
> think I will have a look on it again within the next week. There 
> should be some more improvements in cutting.
>
> WanMil
>
No I prefer to use --generate-sea=polygons. This is not because I prefer 
this mechanism per se, but because I don't like to put 0x4b into 
typfile. When using =polygons I can assign nice white color to the land 
polygon.
Maybe you can change the background polygon code. What we (I) would need is:
No background polygon is needed if either land or sea is covering a 
place. If I use multipolygons I get two polygons (sea and 0x4b on top of 
each other), that is one too much and slows down map panning on etrex.

Therefore the perfect solution would be (for maps incorporating a Typfile):
no 0x4b, but:
sea polygon where there is sea
a land polygon for the rest (preferably not 0x4b but make it configurable).

For maps without typfile, one could experiment with polygons 0x01-0x05.