Nice idea! I'll put that on the todo list for incorporating into the splitter, sounds like a very useful feature to add. What might be even better is if I use those webservices to generate a data file that can be distributed with the splitter itself, so people don't need to have an internet connection when splitting. The static lookup could also be customised to suit individual needs if so desired.
CG> I found it somewhat annoying that my tiles always had identical CG> generic descriptions such as "OSM Map". It made it very difficult to CG> recognise which tiles belonged to which areas, in particular when CG> attempting to select specific tiles on my GPSr. Since my maps could CG> have over 200 tiles, it was tedious to add descriptive names CG> manually. To solve this, I performed the following small hack, which CG> might be interesting to others with a similar predicament: CG> CG> - I created a Perl script which read the tile boundaries from the CG> areas.list file generated by splitter. CG> CG> - For each bounding box, I called a webservice from GeoNames to CG> retrieve a list of populated areas (cities, etc.) within the tile. CG> CG> - For each populated area within the tile, I called another CG> webservice to determine the population of that area. CG> CG> - I determined the city with the largest population, and then wrote CG> the ISO country code and name of the city to the description CG> parameter in template.args. CG> CG> To my astonishment, this worked rather well. CG> CG> Here is an excerpt from the resulting template.args file: CG> CG> [...] CG> mapname: 23000223 CG> description: EE-Tartu CG> input-file: 23000223.osm.gz CG> mapname: 23000224 CG> description: FI-Espoo CG> input-file: 23000224.osm.gz CG> mapname: 23000225 CG> description: FI-Helsinki CG> input-file: 23000225.osm.gz CG> mapname: 23000226 CG> description: RU-Saint-Petersburg CG> input-file: 23000226.osm.gz CG> [...] CG> A description of the webservices I used is at CG> http://www.geonames.org/export/ I used the GeoNames Perl client CG> module to parse the webservice results; this may not have been the CG> most efficient. CG> CG> There are of course many other ways of doing this, and other CG> services and data which can be used. Perhaps this will inspire some CG> of you to create a better solution. CG> CG> Cheers. CG> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev