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

Fri Jan 8 22:25:22 GMT 2010

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

Regards,
Johann