[mkgmap-dev] gui for areas.list ?

Tue Aug 25 17:15:38 BST 2009

Quoting Chris Miller <chris.miller at kbcfp.com>:

>
> L> the tiles rendered with Mkgmap. The red tiles in Denmark are caused
> L> by all the house numbers which cause the guesstimate mechanism
> L> (--max-nodes) of splitter to be fooled in thinking that Mkgmap could
> L> produce working maps for those areas. Splitter should be more
> L> intelligent about determining the max size of an area, ultimately.
>
> Ahh yes, that rings a bell now that you mention it. I'm open to suggestions
> on how this could be improved, unfortunately I don't have enough experience
> with the limits yet to know what might be the best approach. At this stage
> I'm thinking about building up a low-res "density map" (for lack of a better
> term), which would divide the world into MxN areas (probably with   
> their boundaries
> aligned to suit the map resolution) and then tally up the number of   
> nodes/ways/relations
> in each area. Those aggregations could then be used to decide how to group
> areas together into larger tiles. I can see a lot of advantages to this,
> for example:
>
> - The nodes/ways/rels could contribute different (easily   
> customisable) weightings,
> so we can experiment to find the best balance.
> - The algorithm that decides how to group the areas into tiles would be easy
> to adjust and could even be made pluggable.
> - High density areas could be identified and placed in the middle of a tile,
> rather than cut through the middle as is the tendency with the   
> current splitter
> (see eg London).
> - The density map could be paged out to disk and the subdivision performed
> on a portion at a time to save memory without much of a performance hit.
> - The density map could be handed off to a tile editor tool so users could
> take tile complexity into account.
>
> I haven't yet sat down and figured out how it will affect performance and
> memory of the current splitter, but I doubt it'll be a deal breaker and will
> probably even have some benefits.
>
> What do people think (assuming you can even understand my admittedly poor
> description!)?
This sounds like an excellent idea - the density map would ideally be  
a planet map and live in server-land getting updated as OSM gets  
updated.  Users could then download the latest map (or a portion of  
it) when they want to do some manual editing of areas.list.

>
> L> There are also quite a few people who would like to be able to split
> L> tiles because the tiles would otherwise include bits of data from
> L> neighboring countries e.g. across large bodies of water (look at e.g.
> L> France/England/Spain, Zweden/Poland etc). I have no problem with this
> L> type of splitting result, but some apparently do.
>
> Makes sense. I notice the real Garmin maps have tiles that must have at least
> partially been crafted by hand. Eg London is covered very nicely by a single
> tile, various tiles have edges along national borders, bodies of water are
> tiled appropriately and so on. I guess no algorithm's ever going to be able
> to match that :(

Exactly: the ideal process (imho) would work as follows:
1) User opens TileGUI and specifies the region they're interested in  
(preferably, by selecting a rectangular area on a map), or opens a  
pre-specified area that they have previously saved
2) TileGUI downloads the appropriate portion of the current density  
map and automatically generates a set of suggested tiles based on data  
density
3) User manually edits these tiles (e.g. to avoid overlapping  
countries or tiles with huge areas of empty sea, per his/her preference)
4a) TileGUI alerts user if they create a tile which is likely to be too large
4b) TileGUI alerts user if the user's tiles do not completely cover  
the region specified in 1)
5) User presses button and tileGUI spits out an areas.list file