[mkgmap-dev] Suggestion - Make Douglas Peucker Algorithm more Configurable

Fri Jan 8 22:39:40 GMT 2010

On 08.01.2010 23:25, Johann Gail wrote:
>    
>>>> That patch works pretty nice. I upped the value to 40 and that gave
>>>> nice results when zoomed far out.
>>>> Here is the settings that I would find optimal
>>>> resolution 24 == 4 (I think 4 is anyhow the minimum because if less
>>>> than 4 pixels than it ain't an area)
>>>> resolution 23 == 6 ( resolution 23 is not used by all GPS devices if
>>>> resolution 24 and 22 are present)
>>>> resolution 22 == 6
>>>> resolution 21 == 20
>>>> resolution 20 == 40
>>>> resolution 19 == 80
>>>> resolution>18 == 120
>>>>
>>>>          
>>> Just to be sure there is no missunderstanding: You are not able to
>>> set minsizes for each  resolution. You haven't set them, or have you?
>>>        
>> No of course I couldnt
>>      
>>> The SizeFilter itself should shift the minsize according to the
>>> resolution. I.e. if you init it with number 2 the following minsizes
>>> should be uesed:
>>>
>>> resolution 24 = 2
>>> resolution 23 = 4
>>> resolution 22 = 8
>>> resolution 21 = 16
>>> resolution 20 = 32
>>> resolution 19 = 64
>>> resolution 18 = 128
>>>
>>> which matches roughly your demands.
>>>        
>> No my demands were with the current code. I tried out different values
>> and looked at what I seemed to give best results. So according to your
>> system the following values seem well to me:
>> resolution 24 == 1
>> resolution 23 == 8
>> resolution 22 == 48
>> resolution 21 == 320
>> resolution 20 == 1280
>> resolution 19 == 5120
>> resolution 18 == 15360
>> resolution 17 == 30720 ( I doubt anyone will display polygons other
>> than sea at this resolution - so there is not much need here anymore
>> to have the filter - I would not want to have sea polygons being dropped)
>>
>>      
> Sorry, I'm a little confused by the nonlinearity of the values. This
> means that on low resolutions mostly of the polygons will disappear
> (e.g. res 18, all polygons smaller than 15360 garmin units), while on
> higher resolutions there will be nearly no visible effects.
>
> resolution 24 == 1
> resolution 23 == 8          (2*4)
> resolution 22 == 48        (6*8)
> resolution 21 == 320       (20*16)
> resolution 20 == 1280    (40*32)
> resolution 19 == 5120    (80*64)
> resolution 18 == 15360   (120*128)
>
> I had expected the internal power of two from the SizeFilter to be quite
> sensible. But on the other hand it depends on the assignments between
> resolutions and zoom levels.
> In general I had the idea in mind, that with usefull resolutions one
> garmin unit means roughly one pixel at display. So with a set value of 8
> all objects smaller then 8 pixels should be filtered.
>
>    
>> The advantage would be that one can confidently increase the
>> resolution for polygons inside the style-file without getting huge
>> performance drops. Directly going for very high levels in resolution
>> 24/23/22 however did not improve visual quality of my maps, nor make
>> big differences in rendering speed.
>>      
> Very high numbers at low level will DEcrease visual quality, as  some
> visible objects will disappear.
>    
>> Only when zoomed out far (e.g. resolution 20 and using high min_size)
>> performance differences became notable - and also very small areas got
>> dropped that would not be displayed in a "hand drawn" map either).
>>
>>      
> I haven't tried myself, but this would mean, that at resolution 20, 40
> garmin units will be only a few pixels (your words: very small areas).
> This seems a waste of encoding bits to me. Do you have some special
> assignment of zoom levels to resolution levels or are you using the
> default settings?
>
>    
Well I have forests, riverbanks, glaciers and other sometimes "large" 
areas down to 20, but would like them at 19. I have my Polygon file 
attached. I just recently "levelled up" polygons because maps got slow. 
I would like to increase them a bit again. Maybe it would be doable to 
put higher min_sizes if inner polygons are not cut out (at least for 
forests). I have been using theese values with the newest patches by 
WanMil because I do think that they have to be included. Maybe the 
Multipolygon inner cutout should not be done depending on type and 
resolution! (at resolution 20 the only inners I would like to be cut out 
are inners from sea/water/lake polygons. Forest inners should be untouched).

I first had an even higher increase, but then many polygons started to 
get holes because forests are usually not entered as relations but in 
pieces. Speaking in terms of pixels I would prefer something like
resoution 22: 50pixels
resolution 21: 100pixels
resolution 20: 200pixels
resolution 19: 1000pixels
resolution 18: 5000pixels (huge lakes and sea only)

But if you use such "reasonable" values, you will notice a lot of useful 
areas at the resolution not being displayed at all, because they are 
made up of several polygons.
Otherwise I would ramp up even higher.
> Regards,
> Johann
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>    
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: polygons
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20100108/e24403cb/attachment.pl 