[PATCH v2] Reduce number of cuts in multipolygon processing

The patch fixes a NullPointerException (thanks Felix!) which sometimes happened with the first patch. @Marko: I don't know any reason, why this multipolygon patch should trigger your exception. The stacktrace shows that you use a modified Main.java which seems to trigger the Exception. WanMil

okay, new patch seems to be working. On Austria it rather got slower than faster however, but difference is not significant. Also map size increased and did not decrease. Could not yet find out big differences. If you think it is better/more correct (you understand a lot more about it), then from my point of view feel free to commit it.

Forgot to say, I'm using --generate-sea=polygons,... I found generate-sea=multipolygons to be worse. Is --generate-sea=multipolygon now preferrable? Is it faster on GPS? Or is the main factor for using multipolygon, that it works without a TYP-file??

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)

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

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.

Hi WanMil As Felix said, the lesscuts patch and the closewaysoutbox patches conflict. I've attached the patch from applying 'lesscuts' to r1594, resolving in favour of lesscuts where there was a conflict. I'll commit that if there are no problems, but could you let me know what can be done about the mp closeway patch. The code is so completely different between the two patches that I wouldn't like to guess what to do (if anything). ..Steve

Hi WanMil
As Felix said, the lesscuts patch and the closewaysoutbox patches conflict. I've attached the patch from applying 'lesscuts' to r1594, resolving in favour of lesscuts where there was a conflict.
I'll commit that if there are no problems, but could you let me know what can be done about the mp closeway patch. The code is so completely different between the two patches that I wouldn't like to guess what to do (if anything).
..Steve
Hi Steve, v3 of the patch is taken from r1596. I have slightly modified it compared to v2. Just some minor improvements and the merging to the patches that have been already committed. Summary: Reduce number of cuts in multipolygon processing Reduces the number of cuts performed by multipolygon processing by combining the cut of several polygons in one cut instead of n cuts. This speeds up the processing for multipolygons consisting of lots polygons. WanMil
participants (3)
-
Felix Hartmann
-
Steve Ratcliffe
-
WanMil