[mkgmap-dev] overview2 branch
From GerdP gpetermann_muenchen at hotmail.com on Fri Apr 19 08:38:37 BST 2013
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.
- 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