location-autofill=bounds uses a boundary not surrounding the POI
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
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
Hi WanMil, Thank you for your debug information. If the log file says that N 617233095 ;;;;;;Bezirk Innsbruck-Stadt;;Tirol;;AUT;; W 45987333 ;;;;;;Bezirk Innsbruck-Stadt;;Tirol;;AUT;; was assigned to that POI, then from my point of view mkgmap does what it is told to do. It looks like that mkgmap does not find any city name for the correcpsonding mkgmap:city tag since no administrative boundary is present in OSM data. Therefore it leaves the address field for the city name empty. The reason for displaying another city name instead of no one might be found in the address index format or in Garmin software respectively. However, the solution in my case will be to extend the style file by additional rules assigning any other name to the mkgmap:city tag if the desired one cannot be resolved. For example by obtaining the name of the administrative boundary with the next lower admin_level helps to overcome the 'random' city name effect in this case. mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } The the rules in the mkgmap default style only redirects mkgmap to search for the next boundary with higher admin_level. But due to the fact that there is no boundary in the OSM data fitting to the rules, the observed effect occurs. Bernhard
Hi Bernhard,
Hi WanMil,
Thank you for your debug information. If the log file says that
N 617233095 ;;;;;;Bezirk Innsbruck-Stadt;;Tirol;;AUT;; W 45987333 ;;;;;;Bezirk Innsbruck-Stadt;;Tirol;;AUT;;
was assigned to that POI, then from my point of view mkgmap does what it is told to do. It looks like that mkgmap does not find any city name for the correcpsonding mkgmap:city tag since no administrative boundary is present in OSM data. Therefore it leaves the address field for the city name empty. The reason for displaying another city name instead of no one might be found in the address index format or in Garmin software respectively.
Yes, I did not bear in mind that the city name is completely empty. Maybe this info is also helpful for Steve but I will also check the mkgmap code what's happening with elements without a city name.
However, the solution in my case will be to extend the style file by additional rules assigning any other name to the mkgmap:city tag if the desired one cannot be resolved. For example by obtaining the name of the administrative boundary with the next lower admin_level helps to overcome the 'random' city name effect in this case.
mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
The the rules in the mkgmap default style only redirects mkgmap to search for the next boundary with higher admin_level. But due to the fact that there is no boundary in the OSM data fitting to the rules, the observed effect occurs.
The default rules use admin levels 8,7,9 and 10 for the city name. Please let me know if your second austrian rule with admin_level6 should be included in the mkgmap default style. Anyhow we will check whats happening if no city name is assigned. WanMil
Bernhard
On 11/08/12 11:49, WanMil wrote:
Yes, I did not bear in mind that the city name is completely empty. Maybe this info is also helpful for Steve but I will also check the mkgmap code what's happening with elements without a city name.
That is what I think, if the city is empty then the closest city is used (MapBuilder.java:386). I checked with your Il Piacere restaurant example and that is what is happening. I got a different city than you, Aldrans rather than Natters. The city is in the img tile itself, and is not changed by the index. ..Steve
On 11/08/12 11:49, WanMil wrote:
Yes, I did not bear in mind that the city name is completely empty. Maybe this info is also helpful for Steve but I will also check the mkgmap code what's happening with elements without a city name.
That is what I think, if the city is empty then the closest city is used (MapBuilder.java:386). I checked with your Il Piacere restaurant example and that is what is happening.
I got a different city than you, Aldrans rather than Natters.
The city is in the img tile itself, and is not changed by the index.
..Steve
I agree. I wonder if we should change the behaviour if no city name is found should be changed: 1. Is it possible to have an empty city name? I think mkgmap users do not expect that the nearest algorithm is used if city name could not be assigned and location-autofill=nearest is not set. If the city name could not be empty we could set a default city name. 2. The nearest algorithm uses city POIs only. At the time the algorithm was implemented this was a reasonable choice. I would now change that to use all POIs so that neighboured POIs with a city information could be used to find the city name. In this case an addr:city tag of a neighboured POI could also be used to set the city name of surrounding POIs without city information. For backward compatibiilty we could add a new location-autofill option for this. What do you think? WanMil
Hi, Can anyone tell me which Java source code for BentleyOttmann intersection is tested and works well? Regards. David
Hi WanMil, Hi Steve, Thank you for your efforts. Now I know that mkgmap is working very well in terms of the location-autofill process, as long as the desired address information is available in the OSM data :-) From my point of view you do not have to change mkgmap's behaviour if no city name is found. Instead, I've tried to improve the rule set for the location tag assignment and it is working well in Austria, Germany, Italy and parts of Swizzerland. I've introduced a tag for districts for myself and I use it to fill the city tag if no city name is found using the administrative boundaries. For example, like in Innsbruck, the address is city=district and region=region ..., Innsbruck-Stadt, Tirol, AUT On the other hand if a city name is present I concatenate the district tag with the region tag like 'district, region', which provides detailed adress information. For example, with city name ..., Livigno, Sondrio, Lombardia, ITA Thanks and greetings, Bernhard Here is my current rule set, still work in progress... #------------------------------------------------------------------------------ # location # country code mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country!=* & addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=* & is_in:country=* { set mkgmap:country='${is_in:country}' } # federal state, region mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' } mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=* & mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=* & addr:state=* { set mkgmap:region='${addr:state}' } mkgmap:region!=* & is_in:state=* { set mkgmap:region='${is_in:state}' } mkgmap:region!=* & addr:province=* { set mkgmap:region='${addr:province}' } mkgmap:region!=* & is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=* & is_in:region=* { set mkgmap:region='${is_in:region}' } # district, county mkgmap:district!=* & mkgmap:admin_level6=* { set mkgmap:district='${mkgmap:admin_level6}' } mkgmap:district!=* & mkgmap:admin_level7=* { set mkgmap:district='${mkgmap:admin_level7}' } mkgmap:district!=* & addr:district=* { set mkgmap:district='${addr:district}' } mkgmap:district!=* & is_in:district=* { set mkgmap:district='${is_in:district}' } mkgmap:district!=* & is_in:county=* { set mkgmap:district='${is_in:county}' } # city mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=BEL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=CZE & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=CZE & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DNK & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DNK & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DNK & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=FIN & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=FIN & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=ISL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=ITA & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=LUX & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=NOR & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=POL & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:country=POL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=PRT & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=PRT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=SVN & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:country=ESP & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=SWE & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=SWE & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=CHE & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' } mkgmap:city!=* & is_in:municipality=* { set mkgmap:city='${is_in:municipality}' } mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=* & is_in:town=* { set mkgmap:city='${is_in:town}' } mkgmap:city!=* & is_in:village=* { set mkgmap:city='${is_in:village}' } mkgmap:city!=* & is_in:hamlet=* { set mkgmap:city='${is_in:hamlet}' } # remove prefixes mkgmap:country=AUT & mkgmap:district=* { set mkgmap:district='${mkgmap:district|subst:Bezirk |subst:Gemeinde }' } mkgmap:country=CHE & mkgmap:district=* { set mkgmap:district='${mkgmap:district|subst:Bezirk |subst:Verwaltungskreis }' } mkgmap:country=DEU & mkgmap:district=* { set mkgmap:district='${mkgmap:district|subst:Verwaltungskreis |subst:Landkreis }' } mkgmap:country=AUT & mkgmap:city=* { set mkgmap:city='${mkgmap:city|subst:Stadt }' } # concatenate region and district mkgmap:city!=* & mkgmap:district=* { set mkgmap:city='${mkgmap:district}'; delete mkgmap:district; } mkgmap:region=* | mkgmap:district=* { set mkgmap:region='${mkgmap:district}, ${mkgmap:region}'|'${mkgmap:region}'|'${mkgmap:district}' } # postal code mkgmap:postal_code!=* & openGeoDB:postal_codes=* { set mkgmap:postal_code='${openGeoDB:postal_codes}' } mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' } # address mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' } mkgmap:street!=* & addr:place=* { set mkgmap:street='${addr:place}' } mkgmap:street!=* & addr:housename=* { set mkgmap:street='${addr:housename}' } mkgmap:housenumber!=* & addr:housenumber=* { set mkgmap:housenumber='${addr:housenumber}' } mkgmap:phone!=* & phone=* { set mkgmap:phone='${phone}' } mkgmap:is_in!=* & is_in=* { set mkgmap:is_in='${is_in}' }
Hi
I wonder if we should change the behaviour if no city name is found should be changed:
1. Is it possible to have an empty city name? I think mkgmap users do not expect that the nearest algorithm is used if city name could not be assigned and location-autofill=nearest is not set. If the city name could not be empty we could set a default city name.
I think that the autofill option should be completely separate to the bounds option. If you want to use the pre-compiled bounds then use the --bounds option, and to use the autofill feature, use the --location-autofill option. To get both, give both options. I don't much like the results of the autofill options from my experience in the UK at least. I think it is much better for the city name to be empty than wrong. I see two main problems with using nearest city. 1. If the tiles are split so that the correct city node is in another tile then the nearest town will always be wrong. 2. If there is (for example) a large town and a small village 5 miles apart then a node 2 miles from the small village will be allocated to the village, whereas in reallity is much more likely to have an address in the large town.
2. The nearest algorithm uses city POIs only. At the time the algorithm was implemented this was a reasonable choice. I would now change that to use all POIs so that neighboured POIs with a city information could be used to find the city name. In this case an addr:city tag of a neighboured POI could also be used to set the city name of surrounding POIs without city information. For backward compatibiilty we could add a new location-autofill option for this.
What do you think?
Sounds good. How about creating a fall back boundary file by drawing polygons around POIS that have the same city, to be used only when the real boundaries are not complete? ..Steve
Hi
I wonder if we should change the behaviour if no city name is found should be changed:
1. Is it possible to have an empty city name? I think mkgmap users do not expect that the nearest algorithm is used if city name could not be assigned and location-autofill=nearest is not set. If the city name could not be empty we could set a default city name.
I think that the autofill option should be completely separate to the bounds option. If you want to use the pre-compiled bounds then use the --bounds option, and to use the autofill feature, use the --location-autofill option. To get both, give both options.
Thinking your idea out we could completely remove the bounds parameter of the location-autofill option because the bounds parameter does not automatically fill the location. It only adds tags with the boundary names which then can be used in the style file to assign the city/zip/region/country fields. So the idea is to remove the bounds parameter from the location-autofill option. 2nd change is to remove the default value from the bounds option. The LocationHook adds the extra tags from the precompiled bounds only if the bounds parameter points to valid precompiled bounds. The change is not downwards compatible so implementors must change their option files when upgrading. Do you think that's ok?
I don't much like the results of the autofill options from my experience in the UK at least. I think it is much better for the city name to be empty than wrong.
I see two main problems with using nearest city.
1. If the tiles are split so that the correct city node is in another tile then the nearest town will always be wrong.
2. If there is (for example) a large town and a small village 5 miles apart then a node 2 miles from the small village will be allocated to the village, whereas in reallity is much more likely to have an address in the large town.
I aggree. I don't like the nearest algorithm too but it is kept because some mkgmap users voted against removing it.
2. The nearest algorithm uses city POIs only. At the time the algorithm was implemented this was a reasonable choice. I would now change that to use all POIs so that neighboured POIs with a city information could be used to find the city name. In this case an addr:city tag of a neighboured POI could also be used to set the city name of surrounding POIs without city information. For backward compatibiilty we could add a new location-autofill option for this.
What do you think?
Sounds good.
Ok, I will play around a bit.
How about creating a fall back boundary file by drawing polygons around POIS that have the same city, to be used only when the real boundaries are not complete?
Sounds complex. I think there is an algorithm that could create such a polygon. But I fear it does not work good if you have spelling errors in some POIs that produces holes in the boundary polygons. I put that on my list and will check that.
..Steve
WanMil
participants (5)
-
Bernhard Moser -
Bernhard Moser -
David Shi -
Steve Ratcliffe -
WanMil