[mkgmap-dev] gui for areas.list ?From Chris Miller chris.miller at kbcfp.com on 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!
- Previous message: [mkgmap-dev] gui for areas.list ?
- Next message: [mkgmap-dev] gui for areas.list ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list