[mkgmap-dev] gui for areas.list ?

Tue Aug 25 16:18:16 BST 2009

L> Chris Miller wrote:
L> 
>> If you like I could add a parameter to the splitter that generated
>> the KML file automatically so there's no need for the additional
>> script.
>> 
L> That would be great to have. Could the KML file then also be used as
L> an input to splitter?

OK I'll add KML output onto the todo list...  Yes a KML file could be used 
as input to the splitter too, however that's a lot more work since KML files 
can be arbitrarily complex. I suspect the splitter would have to perform 
quite a lot of validation to ensure the areas described within were suitably 
rectangular, aligned etc, otherwise there'd be a lot of questions from people 
wondering why something went wrong with the splitter, mkgmap, or on their 
device. Of course there's no validation to speak of with areas.list files 
currently either, but if people are editing that by hand they generally be 
expected to have a better idea about the kinds of problems they might run 
in to.

Having said that, I'm open to trying to deal with what's been given in a 
KML file and split accordingly, without regard for how sane the boundaries 
are. This would probably be provided as an experiemental/beta feature with 
suitable warnings about it being at your own risk. Over time as we get a 
better feel for how people are using it and what problems arise, we could 
look at providing better support.

L> Most of the stuff should be done client side (OL) and the tiles
L> originate from the OSM server, so there won't be much that bothers my
L> server. But I don't know if you're willing to add a link to a page on
L> a not-affiliated (not directly anyway to the splitter tool) server
L> from within the code. It seems prone to failure some day ;) A link on
L> the Mkgmap/splitter wiki page seems more appropriate to me.

Steve's probably the best person to comment on linking to external sites. 
But wrt the chance of the url changing/breaking in the future, I was intending 
to make it configurable anyway. My idea was to be able to specify something 
like --launchKML, and a browser window would be launched once the subdivision 
had taken place, showing the user something like this: http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=http:%2F%2Fwww.mkgmap.org.uk%2Ftmp%2Fareas.kml&ie=UTF8&z=3

If you can think of a way to do that without having to serve the KML file 
from a server somewhere, I'd be interested to hear your ideas.

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!)?

L> But, as things are now, I'm manually editing the areas.list to get
L> rid of those failed (red) tiles. Unfortunately, doing the splitting
L> of the bboxes by hand is cumbersome work. I also expect mass imports
L> and just sheer manual labour will cause many red tiles to appear in
L> the future. These are the reasons why I was working towards a
L> webbased UI that can do the splitting for me with a simple mouse
L> click.

How about splitting those red areas in half again (taking care with the alignment), 
rather than just getting rid of the areas completely?

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 :(

Chris