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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
