
I'm confused about the way resolution, level and levels interact. I started with a set of supplied styles (actually from Marco Certelli's CreateIMG package) which used resolutions 14, 16, 18, 20, 22 & 24 for various kinds of roads. I wanted to change residential roads to come higher than tertiary roads (resolution=22) but lower than footways & tracks (resolution=24), so I changed them to be at resolution=23. Unfortunately this didn't work -- they appeared and disappeared at the same time as the the resolution=22 tertiary roads. I then changed the levels specification from the supplied levels = 0:24, 1:22, 2:20, 3:18, 4:16 to levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16 and everything sprang into life working as desired. This behaviour was consistent between BaseCamp and my Oregon. The documentation in http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules had led me to think (though I guess it doesn't say so explicitly) that level & levels were meaningful only to the Mkgmap compiler, and were converted to resolution in the final Garmin format map files. As a result I was surprised that changing the levels specification had any effect at all, since all rules used resolution rather than level anyway. Could anyone shed any light on this behaviour? Thanks! -- Cheers, John

Everything goes down to resolutions, but in the resolution / levels file in the style, you still need to define, which resolutions are actually input to the map. If resolution 23 is not actually a resolution that exists (as by default) - then 23 means it will only be put into 24. On 13.09.2012 12:53, John Aldridge wrote:
I'm confused about the way resolution, level and levels interact.
I started with a set of supplied styles (actually from Marco Certelli's CreateIMG package) which used resolutions 14, 16, 18, 20, 22 & 24 for various kinds of roads. I wanted to change residential roads to come higher than tertiary roads (resolution=22) but lower than footways & tracks (resolution=24), so I changed them to be at resolution=23. Unfortunately this didn't work -- they appeared and disappeared at the same time as the the resolution=22 tertiary roads.
I then changed the levels specification from the supplied
levels = 0:24, 1:22, 2:20, 3:18, 4:16
to
levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16
and everything sprang into life working as desired. This behaviour was consistent between BaseCamp and my Oregon.
The documentation in
http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules
had led me to think (though I guess it doesn't say so explicitly) that level & levels were meaningful only to the Mkgmap compiler, and were converted to resolution in the final Garmin format map files. As a result I was surprised that changing the levels specification had any effect at all, since all rules used resolution rather than level anyway.
Could anyone shed any light on this behaviour? Thanks!

Oh, thank you. So would it be worth amending the documentation for o level, to add... Note that if a level number is used which does not appear in the /levels/ specification, then it is treated as the next larger (or should this be smaller?) level number which is present. o resolution, to add... Note that if a resolution number is used which does not appear in the /levels/ specification, then it is treated as the next larger level number which is present. o levels, to add... Note that, if levels is not specified explicitly, then the defaults are as if levels = <whatever> had been specified. -- Cheers, John In article <5051EE89.2060003@gmail.com>, extremecarver@gmail.com says...
Everything goes down to resolutions, but in the resolution / levels file in the style, you still need to define, which resolutions are actually input to the map. If resolution 23 is not actually a resolution that exists (as by default) - then 23 means it will only be put into 24. On 13.09.2012 12:53, John Aldridge wrote:
I'm confused about the way resolution, level and levels interact.
I started with a set of supplied styles (actually from Marco Certelli's CreateIMG package) which used resolutions 14, 16, 18, 20, 22 & 24 for various kinds of roads. I wanted to change residential roads to come higher than tertiary roads (resolution=22) but lower than footways & tracks (resolution=24), so I changed them to be at resolution=23. Unfortunately this didn't work -- they appeared and disappeared at the same time as the the resolution=22 tertiary roads.
I then changed the levels specification from the supplied
levels = 0:24, 1:22, 2:20, 3:18, 4:16
to
levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16
and everything sprang into life working as desired. This behaviour was consistent between BaseCamp and my Oregon.
The documentation in
http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules
had led me to think (though I guess it doesn't say so explicitly) that level & levels were meaningful only to the Mkgmap compiler, and were converted to resolution in the final Garmin format map files. As a result I was surprised that changing the levels specification had any effect at all, since all rules used resolution rather than level anyway.
Could anyone shed any light on this behaviour? Thanks!

On 13/09/12 16:16, John Aldridge wrote:
Oh, thank you. So would it be worth amending the documentation for
o level, to add...
Note that if a level number is used which does not appear in the /levels/ specification, then it is treated as the next larger (or should this be smaller?) level number which is present.
Yes the documentation could be clearer, but that is not quite what is happening. The statement "level 2" is the same as "level 0-2" which means that the item will appear at levels 0, 1 and 2. It will disappear after you zoom out to level 3 or further. For resolution the default end point is 24 so "resolution 23" means "resolution 23-24". It therefore appears at any level which has a resolution of 23 or 24. So for levels = 0:24, 1:22, 2:20, 3:18, 4:16 that just means level 0 but with levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16 it includes levels 0 and 1, which is what you observed. [The wiki also says that you have to write the numbers the wrong way round (resolution 24-23; level 4-2) that was true (a bug) at one time, but now you can write them in any order] ..Steve

In article <505252F5.3090808@parabola.me.uk>, steve@parabola.me.uk says...
Yes the documentation could be clearer, but that is not quite what is happening.
The statement "level 2" is the same as "level 0-2" which means that the item will appear at levels 0, 1 and 2. It will disappear after you zoom out to level 3 or further.
For resolution the default end point is 24 so "resolution 23" means "resolution 23-24". It therefore appears at any level which has a resolution of 23 or 24.
So for levels = 0:24, 1:22, 2:20, 3:18, 4:16
that just means level 0
but with levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16
it includes levels 0 and 1, which is what you observed.
[The wiki also says that you have to write the numbers the wrong way round (resolution 24-23; level 4-2) that was true (a bug) at one time, but now you can write them in any order]
Thank you again. I think the fundamental thing I hadn't grasped was that you can't just put a resolution tag on something to cause it to be displayed at that resolution or greater, but that you have to in some sense "create" the level first with the levels specification before you can assign something to that level using either the resolution or level tag. -- Cheers, John

John Aldridge <jpsa@jjdash.demon.co.uk> writes:
Thank you again. I think the fundamental thing I hadn't grasped was that you can't just put a resolution tag on something to cause it to be displayed at that resolution or greater, but that you have to in some sense "create" the level first with the levels specification before you can assign something to that level using either the resolution or level tag.
Yes. I think what's going on is that in the actual bits, there is (more or less) a 3-bit field that specifies the level index, and then a table of 6 levels, so you can't really encode arbitrary levels. I'm not 100% clear on that, but I think the above gives you a useful mental model.

Hi
Thank you again. I think the fundamental thing I hadn't grasped was that you can't just put a resolution tag on something to cause it to be displayed at that resolution or greater, but that you have to in some sense "create" the level first with the levels specification before you
Thats right. Each level can be thought of a completely separate map. The levels command just tells the device which map to display at each zoom. So for the following there are four maps: levels = 0:24, 1:22, 2:20, 3:18 The least detailed map (map 3) is displayed from zoom 18 and the most detailed (map 0) is displayed from zoom 24. If you use 'level 1' then the feature goes into map 0 and map 1. Whereas if you use 'resolution 22' then mkgmap has to use the 'levels' parameter to work out which levels you mean and then it adds it to appropriate map level. So using 'level' is more direct. The other thing that you need to know is that a Garmin device may just not display a POI if the resolution is too low. So you may have it in the map at a given level, but if the device does not want to display it at that resolution then it won't and there is nothing you can do about that (as far as we know). ..Steve
participants (4)
-
Felix Hartmann
-
Greg Troxel
-
John Aldridge
-
Steve Ratcliffe