Hi, I've generated a map covering Innsbruck in Tyrol (Austria) with the default mkgmap built-in style. Then I was wondering why almost all POI close to the city center have obtained the correct address regarding country, region, streetname and housenumber except the city tag. Instead of showing an address like, for example, ..., 6020 Innsbruck, Bezirk Innsbruck-Stadt , the postcode and the city name from the neighboring town Natters are used resulting to an address like ..., 6161 Natters, Bezirk Innsbruck-Stadt . The address tags are obtained by using the setting location-autofill=bounds - neither is_in nor nearest - with the newest bounds files from [1]. The entry in the style file to get the mkgmap:city tag is mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } from the default mkgmap style. After studying the OSM data I've probaly found the source of the error. As expected mkgmap is searching for an precompiled boundary with mkgmap:admin_level8 tag close to the POI. But in OSM data there exists no boundary with admin_level=8 for the city Innsbruck. The next boundary surrounding the city and therefore the POI is the county border of Innsbruck-Stadt with admin_level=6, see [2], which is used for mkgmap:region correctly. There exists no other administrative boundary with reasonable admin_level for obtaining the city tag SURROUNDING the city and especially the POI. Therefore I would expect that the style file including the line above will not set any mkgmap:city tag associated with the precompiled bounds. But as observed, the administrative boundary of the neighboring county Natters, see [3], is used instead. This boundary, obviously used for obtaining the city tag, is NOT surrounding the POI and therefore should not be used for assigning any address tag to this POI! The reason for this effect might be an imperfection in the precompiling process for the boundary files - please correct me if I'm wrong. Either the location-autofill process is using the nearest boundary with matching admin_level rather than searching for the surrounding one or the OSM data is causing these troubles on the other hand. Both boundaries [2][3] close to the POI share some lines and are implemented as relations. Resolving whether the POI is inside or outside of the boundary might be faulty. Is this effect known or can somebody reproduce this? Greetings, Bernhard [1] http://www.navmaps.eu/wanmil/bounds_20120708.zip [2] http://www.openstreetmap.org/browse/relation/113642 [3] http://www.openstreetmap.org/browse/relation/942840