logo separator

[mkgmap-dev] shapes with holes

From WanMil wmgcnfg at web.de on Tue Jan 29 20:06:32 GMT 2013

> 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
>

I wonder if it is less important to find big enough areas with this 
algorithm. The old problem are white stripes which are ugly. Using the 
described new algorithm there is also a chance that some cuttings are 
too small. But the probability of a small aspect ratio is much higher 
than in the old algorithm. Having a smaller aspect ratio the little 
parts that are missing are also smaller. So I think a small aspect ratio 
might be a kind of indicator how visible the missing parts are.
Maybe it is worthy to try that out. (I am sure at least this algorithm 
is better than the existing :-)

WanMil



More information about the mkgmap-dev mailing list