logo separator

[mkgmap-dev] overview2 branch

From Felix Hartmann extremecarver at gmail.com on Fri Apr 12 14:37:50 BST 2013

Well I finally got around trying out the overview map. For what it is 
supposed to do, it works for me now.
However I would really like to have multiple levels in the overview map.

So for a start, the overview file (to be present in future could contain 
in the first line, a levels definition, just like what is currently used 
in the options file for the normal maps).


As for objects disappearing in between. Garmin does just that in the 
overview map of CN maps. There you have the main important train 
connections in Europe in the highest level of the overview map. They are 
missing in the lowest resolution of the normal maps however, to reappear 
in the next map level.
The reason could be, that displaying the overview map is very CPU/HDD 
effective, while the more is shown on the lowest normal resolution of 
the map, the slower the device/mapsource/basecamp gets.


Still I would really love to have resolutions 10,12,14,16 all with map 
data in the overview map. 16 being empty in the normal maps. And from 
resolution 17 or 18 normal maps with data.
I suppose this is possible with

Sample:
line:0x1e,level=1


However I think it would be much better to have the overview map created 
directly from the osm base material, and not from the .img. Creating 
from .img could be an option too, but it simply only offers limited options.
Image you have in your map:

highway=motorway & network 
<http://wiki.openstreetmap.org/wiki/Key:network>=e-road 
<http://wiki.openstreetmap.org/w/index.php?title=Tag:network%3De-road&action=edit&redlink=1> 
[resolution 14-14 0x01 continue]
highway=motorway [resolution 16-18 0x01 continue]


So clearly the e-road trunk is much more important, while also being of 
type 0x03. If the aim is now to have resolution 16 empty in the map, 
while showing content in the overview map, this is not possible anymore 
using the current approach of reading the finished .img files.
It would be much easier if inside the options file we have:
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18
levels_overview_map = 0:16, 1:14, 2:12, 3:10



And if there is a need to create subsequent overview maps, than an 
existing overview map could be copied and information added based on the 
current algo (copy in data from last used resolution, if resolution 
matches the levels_overview_map pramater. So i.e. copy in map content of 
resolution 16, but don't copy in data from resolution 18 if resolution 
16 is empty)

On 11.04.2013 09:38, GerdP wrote:
> WanMil wrote
>>> Yes, and I think it makes sense to do that. If you add something to the
>>> overview map which
>>> is not shown in the next level, you will see that the boundary lines
>>> disappear in Basecamp when you zoom in
>>> (using full map data, not basemap only).
>> You can implement styles where this happens in the normal map.
>>
>> boundary=administrative & admin_level<3 [0x1e resolution 16-18 continue]
>> boundary=administrative & admin_level<3 [0x1e resolution 22]
>>
>> The boundary will disappear in resolution 19 to 21.
>>
>> Don't know if that makes sense but it is possible. So I don't see a
>> reason why this shouldn't be possible for the overview map too.
> Well, I can change the format of the config file so that one can specify
> the level or resolution which should be used to read the data from.
> This would be an optional parm, with the default being level 0  (resolution
> 24)
> Sample:
> line:0x1e,level=1
> or
> line:0x1e,resolution=22
>
> Open question:
> Should I also add support for multiple levels in the overview map?
>
> This would result in something like this:
> line:type=0x1e,from-resolution=22,to-resolution=13
>
> with the meaning:
> Read the img files, collect all lines with type 0x1e on map resolution 22
> and place them in the overview map on resolution 13.
> The defaults would remain as they are: read only the lowest resolution,
> place everything on level 14.
>
> Gerd
>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-tp5756308p5756594.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130412/e4e0cdcd/attachment.html 


More information about the mkgmap-dev mailing list