logo separator

[mkgmap-dev] location-autofill=bounds uses a boundary not surrounding the POI

From Bernhard Moser berny.moser at gmx.at on Fri Aug 10 01:07:31 BST 2012

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



More information about the mkgmap-dev mailing list