[mkgmap-dev] gui for areas.list ?

Fri Aug 28 18:40:54 BST 2009

L> I don't see the big advantage of having splitter start the browser
L> with a KML argument. It is a simple task for a person to launch
L> Google (or another) site and pass the kml file manually. So I think
L> you can spare yourself the trouble of implementing this.

You're probably right, and given there's no obvious way to deal with passing 
the KML either I'll take your advice and give it a miss.

L> This sound like a lot of work for you and for algorithms while humans
L> can perform this task with ease. So perhaps the current crude (I
L> don't mean in an insulting way!) method might just be fine for the
L> time being and people can fix these kind of problems easily by hand.
L> Especially when working on areas.list files can be simplified through
L> a (webbased perhaps) tool.

I agree with everything you say here, and a user tool will definitely give 
the best and most flexible results. I'd still like to try and improve the 
automated split though for a couple of reasons. I think plenty of people 
(based on a sample size of one - myself ;)) aren't too concerned about where 
the borders are, but would appreciate tiles that hold as much information 
as possible without breaking mkgmap or introducing other problems. Currently 
the tiles vary a lot in what they contain, plus figuring out the right --max-nodes 
threshold involves a bit of trial and error. The better the automated split, 
the less post-processing that is required. Plus, it's an interesting challenge 
to work on :)

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

L> Or do you mean to have splitter split those problem areas again by
L> feeding *only* that problem area and a very low --max-nodes
L> parameter? Because that is a solution that I did not think about
L> before. I just run splitter once a week on 2 halves of the planet and
L> if tiles fail then that's it...

That would certainly do what you want - it would give you a more balanced 
split than Excel because it takes node distribution into account, plus it 
would handle the alignment problem for you. It would even be possible to 
automate this though I'm not sure it's worth the extra complexity of the 
splitter in terms of both code and command line parameters.

L> I guess pure math algorithms would have a hard time, but we can feed
L> them the required information because we have the national border
L> (and city) polygons, so if Mkgmap is going to support polygons
L> instead of bboxes then there is a way...

True... and after chatting to Steve it doesn't sound like adding polygon 
tile support in mkgmap is as hard as I thought it might be, though I don't 
know enough to tackle implementing that myself just yet. I'd be happy to 
work with someone on getting the splitter and mkgmap supporting polygon tiles 
though.

L> In the mean time when there is a GUI then people can optimise the
L> areas.list quite easily. But, so far, I reckoned that having maps
L> available is far better then beautifully crafted tile coordinates but
L> no maps :)

Agreed!