Address search issues
Hi, I'm having a hard time getting the address search to work. I have split the area of Germany from the planet pbf file. Then I build the Garmin IMGs with this commandline: /usr/java/jdk1.6.0_24/bin/java -enableassertions -Xmx2048m -jar /data/gps/mkgmap-r2294/mkgmap.jar and this mkgmap config file: ### description=OSM_Germany_Alps country-name=Germany country-abbr=DE region-name=Germany region-abbr=DE name-tag-list="name:mkgmap,name:de,int_name,name:en,name" overview-mapname=OSM_Germany_Alps overview-mapnumber=10000000 latin1 reduce-point-density=4 merge-lines=yes family-id=1331 product-id=1 series-name=OSM_SRTM_Germany_Alps family-name=OSM_Germany area-name=Germany index style-file=/data/gps/mkgmap-style-toponew_test120611/ tdbfile=no route=yes road-name-pois=0x640a add-pois-to-areas make-opposite-cycleways=yes remove-short-arcs adjust-turn-headings link-pois-to-ways bounds=/data/gps/boundary/bounds/ location-autofill=bounds,is_in,nearest generate-sea=extend-sea-sectors,multipolygon,close-gaps=1000,floodblocker,fbgap=200,fbthres=20,fbratio=0.5 mapname: 10000001 description: FR-Besancon input-file: 10000001.osm.gz ... [more mapname/description/input-file lines] ### The directory /data/gps/boundary/bounds/ contains the unzipped file http://www.navmaps.eu/wanmil/bounds_20120401.zip The "lines", "points" and "polygons" files in my style contain the top lines from the default style which set the location tags AFAIK. I make the mapsource files afterwards: ### description=OSM_SRTM_Germany country-name=Germany country-abbr=DE region-name=Germany region-abbr=DE name-tag-list="name:mkgmap,name:de,int_name,name:en,name" overview-mapname=OSM_SRTM_Germany overview-mapnumber=10000000 latin1 series-name=OSM_SRTM_Germany area-name=Test family-id=1331 product-id=1 family-name=OSM_Germany index tdbfile=yes input-file: 10000001.img ... [more tile files] ### When I try the address search in mapsource I get this: City search for "Berlin": Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU". When I search for a street in Berlin (say, Alexanderstrasse, I can see the POI on the map) I cannot enter "Berlin" in the City field. As soon as I enter the "i" mapsource deletes it again. When I enter the postcode (10178 for Alexanderstrasse, Berlin) the street is found. Mapsource displays "Alexanderstrasse, Not_Set, NOT_SET, DEU". I tried this for various cities and streets. When I build a gmapsupp.img it behaves rather the same in my eTrex Legend HCx. Any ideas? Is there anything wrong with the bounds data or the style files?
On Thu, Jun 14, Ralf kleineisel wrote:
When I try the address search in mapsource I get this:
City search for "Berlin": Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
Looks like somebody played with the admin boarder of Berlin :( I guess you need now: mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Hamburg { set mkgmap:city='${mkgmap:admin_level4}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Berlin { set mkgmap:city='${mkgmap:admin_level4}' } Before the "mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=*" rules. Haven't tried it yet, but the problem sounds the same as we had for Hamburg. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 06/14/2012 10:10 PM, Thorsten Kukuk wrote:
On Thu, Jun 14, Ralf kleineisel wrote:
When I try the address search in mapsource I get this:
City search for "Berlin": Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
Looks like somebody played with the admin boarder of Berlin :(
I guess you need now: mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Hamburg { set mkgmap:city='${mkgmap:admin_level4}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Berlin { set mkgmap:city='${mkgmap:admin_level4}' }
This didn't help. To find the correct values I tried this: highway=* { set mkgmap:city='${mkgmap:admin_level2}' } as the first line in the "lines" file. This gives me "DEU, NOT_SET_, DEU" for a street in Berlin. Then I tried the same for all admin_level values from 3 up to 11. For all of them I get: "Not_set, NOT_SET_, DEU" Seems mkgmap doesn't find any bounds except the level2 one. How can I debug this a bit more?
On 06/14/2012 10:10 PM, Thorsten Kukuk wrote:
On Thu, Jun 14, Ralf kleineisel wrote:
When I try the address search in mapsource I get this:
City search for "Berlin": Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
Looks like somebody played with the admin boarder of Berlin :(
I guess you need now: mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Hamburg { set mkgmap:city='${mkgmap:admin_level4}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=Berlin { set mkgmap:city='${mkgmap:admin_level4}' }
This didn't help.
To find the correct values I tried this:
highway=* { set mkgmap:city='${mkgmap:admin_level2}' }
as the first line in the "lines" file.
This gives me "DEU, NOT_SET_, DEU" for a street in Berlin.
Then I tried the same for all admin_level values from 3 up to 11. For all of them I get: "Not_set, NOT_SET_, DEU"
Seems mkgmap doesn't find any bounds except the level2 one. How can I debug this a bit more?
Hi Ralf, first of all you should have a look at the error messages in the mkgmap log file. To get a logfile you have to configure the logging system as described in http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging After the first tile has been processed maybe you see a message like "LocationHook is disabled because ...". In this case there is a problem with the bounds directory or files. Just post the error message and we will see. If you don't see such a message you might enable a brute force logging. Add the line uk.me.parabola.mkgmap.reader.osm.LocationHook.results.level=FINE to your logging.properties file and start mkgmap with a tile of Berlin again. Your log file will contain the boundary assignments of all OSM elements. This info is only the data of the bounds directory and not of the is_in and neareast algorithm. But these two algorithms should not play a big role in a well mapped region like Berlin. Hopefully you get an idea what's wrong. If not post a small part of the logfile so that I can have a look on it. WanMil
On 07/08/2012 10:37 PM, WanMil wrote:
first of all you should have a look at the error messages in the mkgmap log file. To get a logfile you have to configure the logging system as described in http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
Thanks, now I could start debugging this. It seems that the problem is this line in my config; name-tag-list="name:de,int_name,name:en,name" Without it everything looks good. Any ideas? Originally I had "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the name:mkgmap was set in the style like this; aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*' {add name:mkgmap = '${name}'} This was meant to prefer "name" to "int_name" for elements in german-speaking countries and in non.german-speaking countries prefer the "int_name". But it doesn't matter which of the "name-tag-list" lines I use, it breaks the index.
On Fri, Jul 13, Ralf kleineisel wrote:
On 07/08/2012 10:37 PM, WanMil wrote:
first of all you should have a look at the error messages in the mkgmap log file. To get a logfile you have to configure the logging system as described in http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
Thanks, now I could start debugging this.
It seems that the problem is this line in my config;
name-tag-list="name:de,int_name,name:en,name"
Without it everything looks good.
Any ideas?
Besides that I run into and reported the same problem already right at the beginning, no. But I can confirm that choosing anything else beside "name" as first entry in name-tag-list will most likely break the search index. I had the feeling that name-tag-list is not used in all places, or there is a problem if only some objects supports the other name, but not all in that area. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 07/08/2012 10:37 PM, WanMil wrote: AU
first of all you should have a look at the error messages in the mkgmap log file. To get a logfile you have to configure the logging system as described in http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
Thanks, now I could start debugging this.
It seems that the problem is this line in my config;
name-tag-list="name:de,int_name,name:en,name"
Without it everything looks good.
Any ideas?
Originally I had "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the name:mkgmap was set in the style like this; aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*' {add name:mkgmap = '${name}'}
I propose to use the following rule after the country assignment: arialway=* & mkgmap:country ~ '(DEU|AUT|CHE)' ... The is_in tag is not very reliable.
This was meant to prefer "name" to "int_name" for elements in german-speaking countries and in non.german-speaking countries prefer the "int_name". But it doesn't matter which of the "name-tag-list" lines I use, it breaks the index.
Please be a bit more specific. What do you mean with "it breaks the index" and "is working" or "is not working". Please post your complete style files, your option file and your mkgmap call. If possible give a concrete example, e.g. a specific POI and/or a specific street and write what you see and what you expect. Otherwise I fear that there will be some misunderstandings what you mean. Thanks WanMil P.S.: I am busy at the moment so probably I cannot give you an answer within the next 4 weeks but I will check that when I have time again!
On 07/08/2012 10:37 PM, WanMil wrote:
first of all you should have a look at the error messages in the mkgmap log file. To get a logfile you have to configure the logging system as described in http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
Thanks, now I could start debugging this.
It seems that the problem is this line in my config;
name-tag-list="name:de,int_name,name:en,name"
Please remove the " if you put the option in a config file. name-tag-list=name:de,int_name,name:en,name works for me which means the map contains city, region and country names for all POIs and streets. WanMil
Without it everything looks good.
Any ideas?
Originally I had "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the name:mkgmap was set in the style like this; aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*' {add name:mkgmap = '${name}'}
This was meant to prefer "name" to "int_name" for elements in german-speaking countries and in non.german-speaking countries prefer the "int_name". But it doesn't matter which of the "name-tag-list" lines I use, it breaks the index.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 07/08/2012 10:37 PM, WanMil wrote:
first of all you should have a look at the error messages in the mkgmap log file. To get a logfile you have to configure the logging system as described in http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
Thanks, now I could start debugging this.
It seems that the problem is this line in my config;
name-tag-list="name:de,int_name,name:en,name"
Without it everything looks good.
Any ideas?
Originally I had "name-tag-list="name:mkgmap,name:de,int_name,name:en,name", and the name:mkgmap was set in the style like this; aerialway=* & is_in ~ '.*(Deutschland|Germany|Österreich|Austria).*' {add name:mkgmap = '${name}'}
This was meant to prefer "name" to "int_name" for elements in german-speaking countries and in non.german-speaking countries prefer the "int_name". But it doesn't matter which of the "name-tag-list" lines I use, it breaks the index.
Ralf, is this problem still present or did the removal of " in the name-tag-list option solve your problem? WanMil
On 07/29/2012 05:59 PM, WanMil wrote:
is this problem still present or did the removal of " in the name-tag-list option solve your problem?
The removal of the name-tag-list optionse solved it for me. I adapted my style files to get the same result. I haven't had time to track the issue further down.
Hi,
I'm having a hard time getting the address search to work.
I have split the area of Germany from the planet pbf file.
Then I build the Garmin IMGs with this commandline:
/usr/java/jdk1.6.0_24/bin/java -enableassertions -Xmx2048m -jar /data/gps/mkgmap-r2294/mkgmap.jar
and this mkgmap config file:
### description=OSM_Germany_Alps country-name=Germany country-abbr=DE region-name=Germany region-abbr=DE name-tag-list="name:mkgmap,name:de,int_name,name:en,name" overview-mapname=OSM_Germany_Alps overview-mapnumber=10000000 latin1 reduce-point-density=4 merge-lines=yes family-id=1331 product-id=1 series-name=OSM_SRTM_Germany_Alps family-name=OSM_Germany area-name=Germany index style-file=/data/gps/mkgmap-style-toponew_test120611/ tdbfile=no route=yes road-name-pois=0x640a add-pois-to-areas make-opposite-cycleways=yes remove-short-arcs adjust-turn-headings link-pois-to-ways bounds=/data/gps/boundary/bounds/ location-autofill=bounds,is_in,nearest generate-sea=extend-sea-sectors,multipolygon,close-gaps=1000,floodblocker,fbgap=200,fbthres=20,fbratio=0.5 mapname: 10000001 description: FR-Besancon input-file: 10000001.osm.gz ... [more mapname/description/input-file lines] ###
The directory /data/gps/boundary/bounds/ contains the unzipped file http://www.navmaps.eu/wanmil/bounds_20120401.zip
The "lines", "points" and "polygons" files in my style contain the top lines from the default style which set the location tags AFAIK.
I make the mapsource files afterwards:
### description=OSM_SRTM_Germany country-name=Germany country-abbr=DE region-name=Germany region-abbr=DE name-tag-list="name:mkgmap,name:de,int_name,name:en,name" overview-mapname=OSM_SRTM_Germany overview-mapnumber=10000000 latin1 series-name=OSM_SRTM_Germany area-name=Test family-id=1331 product-id=1 family-name=OSM_Germany index tdbfile=yes input-file: 10000001.img ... [more tile files] ###
When I try the address search in mapsource I get this:
City search for "Berlin": Berlin is found, but mapsource displays "Berlin, NOT_SET, DEU".
When I search for a street in Berlin (say, Alexanderstrasse, I can see the POI on the map) I cannot enter "Berlin" in the City field. As soon as I enter the "i" mapsource deletes it again.
When I enter the postcode (10178 for Alexanderstrasse, Berlin) the street is found. Mapsource displays "Alexanderstrasse, Not_Set, NOT_SET, DEU".
I tried this for various cities and streets.
When I build a gmapsupp.img it behaves rather the same in my eTrex Legend HCx.
Any ideas? Is there anything wrong with the bounds data or the style files?
Hi Ralf, I have a second idea after having a look at your mkgmap parameters. Please try to run both mkgmap calls with tdbfile. I am not sure if the tdbfile=no in the first run has an effect or not. WanMil P.S.: By the way: I recommend to use the precompiled sea data. This compiles much quicker than the previous methods and the results regarding flooding problems are much better. You can enable it using the parameter precomp-sea=<directory with precompiled sea tiles> instead of generate-sea. You can download the sea tile from http://www.navmaps.eu/wanmil/sea_20120614.zip
participants (3)
-
Ralf kleineisel -
Thorsten Kukuk -
WanMil