
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.