[mkgmap-dev] overview2 branch

Sun Apr 21 07:04:18 BST 2013

Hi all,

I am still not sure how to implement the configuration of the overview map ...

The mkgmap source contains many places where the map levels matter, so I don't want to mess that up
by introducing a 2nd option and a lot of if-then-else logic.

Instead, I plan to introduce a single new parm
--min-overview-map-level 
Example:
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18, 6:16,7:14,8:12
min-overview-map-level=6
would mean write all data with level 6, 7, or 8 only to the *_ovm.img files which are later combined in the overview map.

Note that the above levels statement contains 9 levels which is not allowed in the current implementation.
While looking at the corresponding checks I  stumbled about a few questions regarding the levels option.

I wonder if it is allowed to have gaps in the levels?
In other words:
Does it make sense to specify 4 levels
levels=0:24,2:22,4:18,7:16
with the numbers 0,2,4, and 7 instead of 0..3? I guess no, but mkgmap allows it.

The program also allows nonsense like repeated levels with different resolutions:
levels = 0:24, 1:22, 1:21, 2:20, 4:19, 5:18, 6:17, 7:16

I plan to make sure that these statements would be flagged as errors.

Please let me know if that would cause problems with your configuration.

Gerd

Date: Fri, 19 Apr 2013 10:07:25 +0200
From: extremecarver at gmail.com
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] overview2 branch

    as long as mkgkmap then doesn't complain about too many levels...
    fine

    (max levels is 0-7)...

    but of course, that's better.

    And it would be good to have:

    --levels_overview_map=levels code

            Change the way that the levels on the overvie_map correspond
    to the zoom

            levels in the device. See customisation help. Continue from
    normal levels. The default is:

            "6=16, 7=18, 8=12, 9=10", although each style can have

            its own default.

    (I don't know however, if 10 is really needed. Maybe stopping at 12
    is good enough/better.

    -- Here is the levels configuration for the overview map, of City
    Navigator 2009 - NON NT (0:17,1:15,2:13,3:12,4:11,5:10).

    So they use Level5=10 - but it's the empty last one.

    However also in Level4=11 and Level3=12 there is no data.

    The first Level with Data in the overview map is Level 2=13.

    The normal map *.img files have the following resolutions
    (0:23,1:21,3:19,3:18,4:17):

    With level4=17 being as normal empty. (so it seems that the levels
    should not overlap!).

    However also level3=18 seems to be empty.

    So for City Navigator the real resolution table would look like:

    levels=0:23,1:21,2:19

    levels_overview_map=3:17,4:15,5:13

    (without taking into account empty maplevels - which we still need.
    The normal map needs to be 3:18 empty, while the overview map needs
    6:12 empty). So there should not be an overlap of map levels that
    include data.

    Hope the screenshots make it through).

    On 19.04.2013 09:38, GerdP wrote:

      Hi,

Felix suggested to use e.g.
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18
levels_overview_map = 0:16, 1:14, 2:12, 3:10

If one uses style rules that assign level instead of resolution, it would be
unclear
what the level means when overview-levels are also specified.
If I got this right, we have to use something like this:
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18
levels_overview_map = 6:16, 7:14, 8:12, 9:10

Gerd

Felix Hartmann-2 wrote

        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@

          To: 

        mkgmap-dev at .org

          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 
&lt;http://wiki.openstreetmap.org/wiki/Key:network&gt;=e-road 
&lt;http://wiki.openstreetmap.org/w/index.php?title=Tag:network%3De-road&amp;action=edit&amp;redlink=1&gt; 
[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 .org

          &lt;mailto:

        mkgmap-dev at .org

        &gt;

              http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org &www.velomap.org  &lt;http://www.velomap.org&gt;

_______________________________________________ mkgmap-dev mailing 
list 

        mkgmap-dev at .org

          http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list

        mkgmap-dev at .org

          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 .org

        http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-tp5756308p5757684.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/20130421/6dcebd7d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overview_map_CN_2009.png
Type: image/png
Size: 3910 bytes
Desc: not available
Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130421/6dcebd7d/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: normal_map_image.png
Type: image/png
Size: 3452 bytes
Desc: not available
Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130421/6dcebd7d/attachment-0003.png 