[mkgmap-dev] Should inter tile routing still workwhen splittingSplitter results again?

Tue Sep 29 17:04:04 BST 2009

Hi Charlie,

There's definitely some value in doing this, in fact we've already talked 
(albeit at a very high level) about an editor to allow manual creation/adjustment 
of tiles. The problem is the planet osm grows fairly organically and this 
means the tile boundaries will always be in a state of flux. I think something 
akin to the splitter will still be needed to at least provide the editor 
with a starting point, and to provide density information so the person using 
the editor knows when a tile has become 'too big'. Without that information, 
a lot of trial and error would be required and keeping the planet_areas.list 
file up to date would be a lot of work.

Here are some of the things I think we need:

- Generation of a density map for ways and relations (currently we only have 
nodes, which gives only a very crude approximation of how big a tile should 
be). This is very useful for both manual and automated splitting.
- Support for non-rectangular tiles in both the splitter and mkgmap.
- Some recognition by the splitter of country/city/coastline boundaries, 
so it can try to avoid cutting tiles across these boundaries where possible.
- A user tool that provides visual editing of an areas.list file based on 
density maps of nodes/ways/relations. Ideally this would allow an automated 
areas.list to be used as a starting point as well as creating one from scratch.

I have plenty of ideas for all the above and more, as always it's just a 
matter of finding time to work on them.

The way I see it there's room for both automated and manual splitting, they're 
not mutually exclusive. I think the automated splitting can be improved significantly 
still, perhaps even to the point where it's good enough for most people. 
And the better the automated split, the less effort is required to manually 
tweak it afterwards.

Chris

CF> More and more, I'm thinking that a pre-defined areas.list for the
CF> world will eventually be the way to go.  It's surely the way that
CF> Garmin works, and
CF> - It would allow tiles to be aligned around major cities (rather
CF> than
CF> chopping them in half)
CF> - It would stop tiles overlapping different countries wherever
CF> possible (and given the geometric constraints of the tiles
CF> themselves
CF> - though didn't someone say that non-rectangular tiles were
CF> possible?)
CF> - It means that tiles could be labelled appropriately (e.g. by
CF> state/county) without having to rely on geonames or whatever
CF> On the other hand, I realise that automated area.list generation is
CF> helpful whilst OSM matures, and that it avoids having to maintain an
CF> areas.list (which could be a lot of work as planet.osm grows in
CF> size).
CF> But once a working draft planet_areas.list was available, the sort
CF> of scripts that Lambertus has already created could easily be
CF> adapted
CF> to flag broken tiles (which could then be fixed by hand).
CF> 
CF> So my question to this list is: is there any value in an effort to
CF> manually develop areas.list files for countries, using a set of
CF> mutually-agreed criteria?  Or are most people happy with automated
CF> splitting?
CF> 
CF> --
CF> Charlie