Re: [mkgmap-dev] Suggestion - Make Douglas Peucker Algorithm more Configurable
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
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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Felix Hartmann -
Johann Gail