[mkgmap-dev] overview2 branch
From Felix Hartmann extremecarver at gmail.com on Fri Apr 19 09:07:25 BST 2013
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
>>> <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 .org
>> <mailto:
>> 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 <http://www.velomap.org>
>>>
>>> _______________________________________________ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130419/15a50480/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/20130419/15a50480/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/20130419/15a50480/attachment-0003.png
- Previous message: [mkgmap-dev] overview2 branch
- Next message: [mkgmap-dev] overview2 branch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list