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.