[mkgmap-dev] overview2 branch

Wed Apr 17 08:14:00 BST 2013

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=e-road
    [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

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130417/2747cf4b/attachment-0001.html 