WanMil wrote
I think it is not a good idea to focus on the 250 nodes limit. This creates an implicit rule about the further processing after the multipolygon has been calculated. And that will fail at some time in future. (e.g. the java Area object is also used in the AreaClipper)
Without changing the splitting with the java Area object you might also change the cutting procedure a little bit. Instead of completely surrounding the inner polygons you might create singular polygons without holes by partly surrounding the inner polygons. The algorithm should not too complex if you have the information about the shortest distances. I have implemented a similar algorithm a long time ago when I tried a similar approach. But I abandoned because the calculations of the shortest distances took much too long (I used a visibility graph calculated by an external library).
This change makes it possible to keep the java Area calculations until we find a good replacement.
I wanted to implement that, but I did not find an efficient way to calculate equally sized areas. If I just cut somewhere it is likely to have again small stripes. That's why I think that we should not use java Area for this, but I agree that a replacement isn't hard to find. Looks so easy and is so complicated ;-) Gerd Gerd -- View this message in context: http://gis.19327.n5.nabble.com/shapes-with-holes-tp5745424p5747089.html Sent from the Mkgmap Development mailing list archive at Nabble.com.