[mkgmap-dev] Fun with splitter tile descriptions

Wed Sep 9 16:07:25 BST 2009

Well I wasn't planning on bundling the whole thing. My idea was to create 
a grid that's the same resolution as the splitter's density map (typically 
8192x4096), I only need to store some simple summary data (a reference to 
the predominant country/city, plus perhaps a weighting based on population) 
for each grid square and use that to figure out what each tile should be 
called based on the grid squares it covers. That still works out to be quite 
a lot of data (70MB+) but it can probably be made coarser still, it'll compress 
extremely well, and the whole thing can be generated from code as a one-off 
job rather than shipped with the splitter.

I don't think performance will be a problem, it shouldn't take too long to 
process and a lot of it could probably be done in background thread(s). Memorywise, 
even the most memory hungry implementation would only add ~100MB to the first 
stage of the split which isn't an issue now. Plus of course it would be optional 
anyway.

It's an interesting point you make about extracting the data from the osm 
file instead. I can't see that being nearly as reliable however, plus as 
you suspected it would put a larger burden on the splitter in terms of both 
complexity and performance. On nice thing about handling it via webservice-derived 
lookups is that the generated lookup table could also be used by a 3rd party 
area editing tool, in much the same way as the splitter's density maps could 
be. Having a good density map and country/city map of the planet together 
open up a lot of possibilities for both automated and manual generation of 
split areas beyond what raw osm files can provide.

Chris

CG> GeoNames does provide downloadable files for offline use. (Many
CG> people seem to import the data into a MySQL or PostgreSQL DB for
CG> faster access and queries.) See http://download.geonames.org/export/
CG> 
CG> The complete allCountries.zip file is about 175MB though.
CG> 
CG> I wonder if the splitter could perform this analysis while splitting
CG> the OSM data? The data should all be in the relevant .osm file. Of
CG> course if this significantly reduces performance or increases memory
CG> requirements, then it's not a good idea.
CG> 
CG> Cheers.