Maximum map resolutions people use
I'm looking into building a density map to help improve the splitting (whether the splitting be automated or done via a GUI tool), and I'm trying to get a feel for what the memory and disk overhead will be using this approach. In particular, I'm interested in finding out what the highest number is that people are using for the --resolution parameter in the splitter. Is anyone using a value of 20 or higher? If so, what is the bounding box of the osm file that you are splitting? eg Europe's bounding box is (34.43055,-31.78259) - (82.35188,69.41235) while the whole planet file's bounding box is (-90,-180) - (90,180). If you're unable to view the start of the osm file due to its size or because it's compressed or whatever, just let me know which osm file it is and I'll figure it out from there. Many thanks, Chris
I never used the --resolution parameter as I don't know what it means and does to the output/maps. Maybe I missed a discussion about it earlier, but can you explain again? As you probably know, I split two files that to be able to cover the whole world: A North/South America file and one that contains the rest (I call it Eurasia). The max-nodes is set to 1.200.000 and problem areas are divided further by hand. Hope this info helps.
L> I never used the --resolution parameter as I don't know what it means L> and does to the output/maps. Maybe I missed a discussion about it L> earlier, but can you explain again? Oh... I was about to point you to the documentation on the website but you've just made me realise that there isn't any documentation for that parameter yet! Whoops, I'll add it... I think (but am not 100% sure - SteveR, can you please comment?) it should be described something like this: --resolution=13 Rounds the split areas off so they are suitably aligned to use with mkgmap at the specified resolution. The resolution value you supply should be less than or equal to the lowest resolution value you plan to use in mkgmap. For example, if you are using --levels=0:24,1:22,2:20 in mkgmap, the resolution you supply here must be 20 or less. L> As you probably know, I split two files that to be able to cover the L> whole world: A North/South America file and one that contains the L> rest (I call it Eurasia). The max-nodes is set to 1.200.000 and L> problem areas are divided further by hand. Hope this info helps. Thanks. If you're splitting even the whole planet using the default resolution of 13 then there won't be a problem with the density map at all. Chris
I've just chatted to Steve about this and it turns out my description below is incorrect. What really matters is the resolution of the overview map, NOT the resolution of the lowest zoom level you're using. Given that mkgmap is currently hard-coded to use a resolution of 14 for the overview map, there's no need for anyone to be changing the --resolution parameter in the splitter just yet. This is also good news for the density map code I'm working on, it means I don't have to worry too much about the amount of memory it will require. Chris L>> I never used the --resolution parameter as I don't know what it L>> means and does to the output/maps. Maybe I missed a discussion about L>> it earlier, but can you explain again? L>> CM> Oh... I was about to point you to the documentation on the website CM> but you've just made me realise that there isn't any documentation CM> for that parameter yet! Whoops, I'll add it... CM> CM> I think (but am not 100% sure - SteveR, can you please comment?) it CM> should be described something like this: CM> CM> --resolution=13 CM> Rounds the split areas off so they are suitably aligned to use with CM> mkgmap CM> at the specified resolution. The resolution value you supply should CM> be less CM> than or equal to the lowest resolution value you plan to use in CM> mkgmap. For CM> example, if you are using --levels=0:24,1:22,2:20 in mkgmap, the CM> resolution CM> you supply here must be 20 or less. L>> As you probably know, I split two files that to be able to cover the L>> whole world: A North/South America file and one that contains the L>> rest (I call it Eurasia). The max-nodes is set to 1.200.000 and L>> problem areas are divided further by hand. Hope this info helps. L>> CM> Thanks. If you're splitting even the whole planet using the default CM> resolution of 13 then there won't be a problem with the density map CM> at all. CM> CM> Chris
Chris Miller wrote:
I've just chatted to Steve about this and it turns out my description below is incorrect. What really matters is the resolution of the overview map, NOT the resolution of the lowest zoom level you're using.
overview map is at 15 AFAIK, are you sure it's 16? Anyhow we would really need not an empty overview map but overview map with say all objects inside of the last map level. Say you specify down to 16, then everything at 16 should be put into the overview map (say huge cities/capitals, national boardes, motorways) and the map themselves start at 17 or 18. This would give a good performance improvement when panning far out on GPS. Currently even having only very basic info in say level 16 will be quite slow. If I were creating maps for myself only I would only go down to 18, and use basemap on GPS from 17 down as it is more suitable at those resolutions, however then in Mapsource orientation gets more difficult (as our overviewmap is empty).
Given that mkgmap is currently hard-coded to use a resolution of 14 for the overview map, there's no need for anyone to be changing the --resolution parameter in the splitter just yet. This is also good news for the density map code I'm working on, it means I don't have to worry too much about the amount of memory it will require.
Chris
L>> I never used the --resolution parameter as I don't know what it L>> means and does to the output/maps. Maybe I missed a discussion about L>> it earlier, but can you explain again? L>> CM> Oh... I was about to point you to the documentation on the website CM> but you've just made me realise that there isn't any documentation CM> for that parameter yet! Whoops, I'll add it... CM> CM> I think (but am not 100% sure - SteveR, can you please comment?) it CM> should be described something like this: CM> CM> --resolution=13 CM> Rounds the split areas off so they are suitably aligned to use with CM> mkgmap CM> at the specified resolution. The resolution value you supply should CM> be less CM> than or equal to the lowest resolution value you plan to use in CM> mkgmap. For CM> example, if you are using --levels=0:24,1:22,2:20 in mkgmap, the CM> resolution CM> you supply here must be 20 or less. L>> As you probably know, I split two files that to be able to cover the L>> whole world: A North/South America file and one that contains the L>> rest (I call it Eurasia). The max-nodes is set to 1.200.000 and L>> problem areas are divided further by hand. Hope this info helps. L>> CM> Thanks. If you're splitting even the whole planet using the default CM> resolution of 13 then there won't be a problem with the density map CM> at all. CM> CM> Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, Chris Miller wrote:
In particular, I'm interested in finding out what the highest number is that people are using for the --resolution parameter in the splitter. Is anyone using a value of 20 or higher? If so, what is the bounding box of the osm file that you are splitting?
for my topo map Germany I use: levels = 0:24,1:23,2:22,3:21,4:20,5:18,6:16,7:14 with: --bounding-box left=5.8 right=15.1 bottom=47.2 top=55.2
participants (4)
-
Chris Miller -
Felix Hartmann -
Lambertus -
Ralf Kleineisel