[mkgmap-dev] overview2 branch

Thu Apr 18 20:22:01 BST 2013

I think *_ovm.img is also better than memory.

As for not having the same resolution in both the .img file, and the 
overview map. I don't know. Maybe it even works. (as the overview map is 
not transferred to the GPS, trying it out won't do any harm, except in 
case of failure to recreate the map without overlap in the overview img).
And for the style - I really think just adding it to the options file is 
perfect. In case you want to change the level coordination (e.g. in 
general start the overview map at resolution 16, for continents start it 
at 15) would be very easy (well maybe a command line parameter for 
overview map levels in addition even better?). Much easier than a 
separate style.

And even if the overview map is created with different style, I don't 
think this does any harm - The overview map is practically independent 
of the rest of the map (except that it needs to reference the individual 
.img files).
On 17.04.2013 09:14, Gerd Petermann wrote:
> Hi all,
>
> I think I understand now better why Felix wouldd prefer to create the 
> overview map directly from the OSM data, but this requires a change in 
> the program logic:
> Up to now the normal processing is that one mkgmap "job" reads one OSM 
> file and writes one img.
> If options like --gmapsupp, --index, --tdbfile etc. are used, the main 
> program finally starts so-called combiners that read the *.img files 
> and produce the additional files.
>
> Now, to implement your idea, we have to change the logic so that a 
> normal job writes one *.img and one additional file (e.g. *_ovm.img) 
> with the overview map data .
> A final overview combiner would read the *_ovm.img files and combine 
> them in the overview map.
> Another alternative would be to collect the overview data in memory, 
> but this would require heap and some synchronization between the 
> different jobs (threads), so I'd prefer
> writing the additional files as this seems easier to me.
>
> If I got you right, the only needed configuration would be the -- 
> levels_overview_map option to say which levels (resolutions) are 
> written to the *.img files and which are for the *_ovm.img files. 
> assume that we must make sure that the two level statements do not 
> overlap so that you can't have the same resolution in both the *.img 
> files and the overview map?
>
> I think I like this solution because it means that I don't have to 
> find a new user interface for the overview map, and it also reduces 
> the maintenance work for the map creators.
>
> I don't know how much work it would be to implement the writing of the 
> *_ovm.img, and I see a few potential problems if the *.img files and 
> the *_ovm.img files are not all created with the
> same style.
>
> Any comments?
>
> Gerd
>
> ------------------------------------------------------------------------
> Date: Fri, 12 Apr 2013 15:37:50 +0200
> From: extremecarver at gmail.com
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] overview2 branch
>
> 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  <mailto: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  <http://www.velomap.org>
>
> _______________________________________________ mkgmap-dev mailing 
> list mkgmap-dev at lists.mkgmap.org.uk 
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> 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/20130418/9a8e7b60/attachment.html 