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

Fri Aug 10 17:24:28 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

Bernhard,

thanks for your detailed report.

I confirm that some (not all) POIs and some streets get the wrong city 
information!

The reason seems to be a problem with the index file format which is not 
100% known. I can confirm that the problem is not bounds related.

I have compiled the map using the latest mkgmap r2313 and with detailed 
logging of the location assignment 
(uk.me.parabola.mkgmap.reader.osm.LocationHook.results.level=FINE). My 
mkgmap parameters are:
location-autofill=bounds
latin1
bounds=bounds_20120508.zip
remove-short-arcs
add-pois-to-areas
link-pois-to-ways
net
route
tdbfile
index
nsis

My test candidate is "Anichstrasse" 
(http://www.openstreetmap.org/browse/way/45987333) in the city centre of 
Innsbruck and a restaurant 
(http://www.openstreetmap.org/browse/node/617233095) located at 
Anichstrasse.

Both elements are assigned with "6161 Natters, Bezirk Innsbruck-Stadt". 
But the log of the location assignment shows that the bounds information 
is assigned correctly:
N 617233095 ;;;;;;Bezirk Innsbruck-Stadt;;Tirol;;AUT;;
W 45987333 ;;;;;;Bezirk Innsbruck-Stadt;;Tirol;;AUT;;

So maybe mkgmap writes the address index incorrectly. Steve, do you have 
any idea?

WanMil