Hi all, I like to merge the branch to the trunk, but I first want to change the configuration. I like to change the settings like this: When mkgmap creates an overview map, it adds by default all elements that are contained in the lowest resolution of the *.img files. If parameter --overview-cfg is given, mkgmap uses the filters specified in this file. In other words, the options --x-overview-add-points, --x-overview-add-lines, and --x-overview-add-polygons will be removed, and the default overcview-cfg file is like point:* line:* polygon:* Is that ok? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-tp5756308.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Tue, Apr 09, GerdP wrote:
Is that ok?
Fine with me, in the end this is what I use already today. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi, thanks for the quick feedback. I've committed r2564 with these changes. Gerd Thorsten Kukuk wrote
On Tue, Apr 09, GerdP wrote:
Is that ok?
Fine with me, in the end this is what I use already today.
Thorsten
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-tp5756308p5756345.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
I have another suggestion: Since the overview config file is very much related to the styles, why not make a file called 'overview' in the styles directory that mkgmap reads by default (so --overview-cfg:.... is not needed, unless you want to point it to a certain file somewhere else). The overview file in the default style looks like this: # filter for overview map line:* point:* polygon:* Anyone who want to change the default can find it easily. --overview-cfg:.... is optional, if not specified, mkgmap looks in the style directory for the file "overview" If this file does not exist, the overview map will be empty (old situation).
thanks for the quick feedback. I've committed r2564 with these changes.
Gerd
Am 09.04.2013 22:31, schrieb Minko:
I have another suggestion:
Since the overview config file is very much related to the styles, why not make a file called 'overview' in the styles directory that mkgmap reads by default (so --overview-cfg:.... is not needed, unless you want to point it to a certain file somewhere else). The overview file in the default style looks like this:
# filter for overview map line:* point:* polygon:*
Anyone who want to change the default can find it easily. --overview-cfg:.... is optional, if not specified, mkgmap looks in the style directory for the file "overview" If this file does not exist, the overview map will be empty (old situation). Hi This sounds more useful for me.
Just a question if I got it right. A object that should be shown in overview-map must be in lowest level and must be match to the rules in overview-filter? So if there are only boundaries in level 14 and city-points only shown in level 16, then its not possible to display both in overview, exept changing both to the same level? Henning
Hi,
Anyone who want to change the default can find it easily. --overview-cfg:.... is optional, if not specified, mkgmap looks in the style directory for the file "overview" If this file does not exist, the overview map will be empty (old situation). Hi This sounds more useful for me.
OK, I try to implement that.
Just a question if I got it right. A object that should be shown in overview-map must be in lowest level and must be match to the rules in overview-filter? So if there are only boundaries in level 14 and city-points only shown in level 16, then its not possible to display both in overview, exept changing both to the same level?
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). Ciao, Gerd
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. WanMil
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.
Open question: Should I also add support for multiple levels in the overview map?
Do you mean, it will be possible to show motorways at resolution 14, and borders at 13-14? If you can, that would be great. I dont see an advantage of getting map elements that are not displayed anymore on the lowest map level (resolution 16) which suddenly appears again on the overview map at even lower levels. I dont think this makes sense, if something is missing, it should be added in the style file at the lowest map level.
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
On Thu, Apr 11, Minko wrote:
I dont see an advantage of getting map elements that are not displayed anymore on the lowest map level (resolution 16) which suddenly appears again on the overview map at even lower levels. I dont think this makes sense, if something is missing, it should be added in the style file at the lowest map level.
I fully agree. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Should I also add support for multiple levels in the overview map?
Do you mean, it will be possible to show motorways at resolution 14, and borders at 13-14? If you can, that would be great.
yes, that is possible and I want to implement it, but I'd like to fix the open routing problems first.
I dont see an advantage of getting map elements that are not displayed anymore on the lowest map level (resolution 16) which suddenly appears again on the overview map at even lower levels. I dont think this makes sense, if something is missing, it should be added in the style file at the lowest map level.
ok, so I think I counted two votes pro and three contra for this. Since it is rather easy to implement and has no disadvantage for those that don't want to use it I will probably also implement it. I just have to find a user friendly interface ... Gerd
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:
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
WanMil wrote 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@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
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@gmail.com To: mkgmap-dev@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@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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@gmail.com To: mkgmap-dev@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@lists.mkgmap.org.uk <mailto:mkgmap-dev@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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@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
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@.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@.org
<mailto:
mkgmap-dev@.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@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- 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.
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@.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@.org <mailto: mkgmap-dev@.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@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.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@.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@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
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@gmail.com To: mkgmap-dev@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@.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@.org <mailto: mkgmap-dev@.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@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.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@.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@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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Henning Scholland -
Minko -
Thorsten Kukuk -
WanMil