[mkgmap-dev] gui for areas.list ?

Tue Aug 25 17:47:55 BST 2009

CF> This sounds like an excellent idea - the density map would ideally
CF> be  a planet map and live in server-land getting updated as OSM gets
CF> updated.  Users could then download the latest map (or a portion of
CF> it) when they want to do some manual editing of areas.list.
CF>
CF> Exactly: the ideal process (imho) would work as follows:
CF> 1) User opens TileGUI and specifies the region they're interested in
CF> (preferably, by selecting a rectangular area on a map), or opens a
CF> pre-specified area that they have previously saved
CF> 2) TileGUI downloads the appropriate portion of the current density
CF> map and automatically generates a set of suggested tiles based on
CF> data density
CF> 3) User manually edits these tiles (e.g. to avoid overlapping
CF> countries or tiles with huge areas of empty sea, per his/her
CF> preference)
CF> 4a) TileGUI alerts user if they create a tile which is likely to be
CF> too large
CF> 4b) TileGUI alerts user if the user's tiles do not completely cover
CF> the region specified in 1)
CF> 5) User presses button and tileGUI spits out an areas.list file

Sounds about right. The only thing I'm not sure of is whether it'll be viable 
to serve the density map from a server - users may need to generate it themselves, 
particularly if they're using relatively high target resolutions. My current 
thinking is that a full planet density map (uncompressed) would require roughly 
2048*2048*8 bytes = 32MB at the default resolution of 13, but each extra 
step in resolution increases the space required by a factor of 4 (ie resolution 
10 = 2GB). It should however be possible to reduce that requirement using 
some sort of sparse matrix (since the oceans and remote areas are empty), 
quadtree partitioning, or other compression techniques. I'll give it some 
thought.

While we're on the topic of improving the tile generation, how much work 
would be required to add support for non-rectangular tiles in mkgmap?

Chris