Address index for multi-country map
I try to build a map of Germany, Switzerland, Austria and Czech Republic with a functional address index. I downloaded the Geofabrik extracts for those countries, combined them (after conversion to o5m format) with osmconvert, split them, and create the map. The result is quite mixed: some places show up below "Country" instead of Germany, e.g. - Addresses - Spell Country: Country - Spell City: Krummennaab - Enter Street Name: (stopped here, works) whilst - Addresses - Spell Country: Deutschland - Spell City: Krummennaab - No Results found Some places show up below "Deutschland", but (almost) no road is available: - Addresses - Spell Country: Deutschland - Spell City: Erlangen - Enter Street Name: (blank) - only "Buckenhofer Weg" available of a town with more than 100000 inhabitants... whilst - Addresses - Spell Country: Country - Spell City: Erlangen - Enter Street Name: (blank) - lists many roads of the town Near my home in Bayreuth is "Geseeser Weg". I choose that example because that street name does not exist so often. - Addresses - Spell Country: Country - Spell City: (Search All) - Enter Street Name: Geseeser - No Results found but - Addresses - Spell Country: Deutschland - Spell City: (Search All) - Enter Strret Name: Geseeser - lists "Geseeser Straße" and "Geseeser Weg" - select the latter - Enter House Number: 1 - lists "Geseeser Weg Altstadt Deutschland" and "Geseeser Weg Schnörleinsmühle". Since the part of Bayreuth is "Altstadt" (but no one would write that down as part of the address - it is Geseeser Weg 1, 95447 Bayreuth) select that - shows correctly on the map Let's try an example in Czeck Republic: Dukelská Ulica in Sokolov - Addresses - Spell Country: Ceská Republica - Spell City: Sokolov - No Results found but - Addresses - Spell Country: Country - Spell City: Sokolov - Enter Street name: Dukelská - Enter House Number: 1 - shows correctly on the map I know that I can use command line parameters for mkgmap: --country-name=Deutschland ^ --country-abbr=DEU ^ but that's not approriate here: there are 4 different countries to deal with. Otherwise, the parameters do their job correctly. According to the documentation, the style file should help mkgmap determine the country, and both my lines and points files say on their top: include 'inc/address'; How to solve this problem? Thanks for your hints.
Hello Bernhard, please post your style files and the mkgmap parameters you are using. Thanks! WanMil
I try to build a map of Germany, Switzerland, Austria and Czech Republic with a functional address index. I downloaded the Geofabrik extracts for those countries, combined them (after conversion to o5m format) with osmconvert, split them, and create the map.
The result is quite mixed: some places show up below "Country" instead of Germany, e.g. - Addresses - Spell Country: Country - Spell City: Krummennaab - Enter Street Name: (stopped here, works) whilst - Addresses - Spell Country: Deutschland - Spell City: Krummennaab - No Results found
Some places show up below "Deutschland", but (almost) no road is available: - Addresses - Spell Country: Deutschland - Spell City: Erlangen - Enter Street Name: (blank) - only "Buckenhofer Weg" available of a town with more than 100000 inhabitants... whilst - Addresses - Spell Country: Country - Spell City: Erlangen - Enter Street Name: (blank) - lists many roads of the town
Near my home in Bayreuth is "Geseeser Weg". I choose that example because that street name does not exist so often. - Addresses - Spell Country: Country - Spell City: (Search All) - Enter Street Name: Geseeser - No Results found but - Addresses - Spell Country: Deutschland - Spell City: (Search All) - Enter Strret Name: Geseeser - lists "Geseeser Straße" and "Geseeser Weg" - select the latter - Enter House Number: 1 - lists "Geseeser Weg Altstadt Deutschland" and "Geseeser Weg Schnörleinsmühle". Since the part of Bayreuth is "Altstadt" (but no one would write that down as part of the address - it is Geseeser Weg 1, 95447 Bayreuth) select that - shows correctly on the map
Let's try an example in Czeck Republic: Dukelská Ulica in Sokolov - Addresses - Spell Country: Ceská Republica - Spell City: Sokolov - No Results found but - Addresses - Spell Country: Country - Spell City: Sokolov - Enter Street name: Dukelská - Enter House Number: 1 - shows correctly on the map
I know that I can use command line parameters for mkgmap: --country-name=Deutschland ^ --country-abbr=DEU ^ but that's not approriate here: there are 4 different countries to deal with. Otherwise, the parameters do their job correctly.
According to the documentation, the style file should help mkgmap determine the country, and both my lines and points files say on their top: include 'inc/address';
How to solve this problem? Thanks for your hints.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello WanMil, please find enclosed the style used in that map and teh batch routines. In case that folder paths might play a role: the script is E:\Maps\Development\Europe.Car\_3_MakeMap.bat; it is started by a double click in WIndows Explorer, i.e. the current working directory is the folder containing the script. The style is not in a sub-directory of it. My preprocessor (attached is the output of my preprocessor, I zipped it for the purpose of attaching it to this email) writes it to E:\Maps\Development\Style.Mapnik\Mapnik.Car. The version of mkgmap is the patch provided by Steve for the numerical comparison of two tags (see http://gis.19327.n5.nabble.com/Numerical-comparison-of-two-tags-td5783600.ht...), I copied the jar into the folder of version 2724. Thanks alot for analysing. Regards, Bernhard Am 04.11.2013 20:18, schrieb WanMil:
Hello Bernhard,
please post your style files and the mkgmap parameters you are using.
Thanks! WanMil
I try to build a map of Germany, Switzerland, Austria and Czech Republic with a functional address index. I downloaded the Geofabrik extracts for those countries, combined them (after conversion to o5m format) with osmconvert, split them, and create the map.
The result is quite mixed: some places show up below "Country" instead of Germany, e.g. - Addresses - Spell Country: Country - Spell City: Krummennaab - Enter Street Name: (stopped here, works) whilst - Addresses - Spell Country: Deutschland - Spell City: Krummennaab - No Results found
Some places show up below "Deutschland", but (almost) no road is available: - Addresses - Spell Country: Deutschland - Spell City: Erlangen - Enter Street Name: (blank) - only "Buckenhofer Weg" available of a town with more than 100000 inhabitants... whilst - Addresses - Spell Country: Country - Spell City: Erlangen - Enter Street Name: (blank) - lists many roads of the town
Near my home in Bayreuth is "Geseeser Weg". I choose that example because that street name does not exist so often. - Addresses - Spell Country: Country - Spell City: (Search All) - Enter Street Name: Geseeser - No Results found but - Addresses - Spell Country: Deutschland - Spell City: (Search All) - Enter Strret Name: Geseeser - lists "Geseeser Straße" and "Geseeser Weg" - select the latter - Enter House Number: 1 - lists "Geseeser Weg Altstadt Deutschland" and "Geseeser Weg Schnörleinsmühle". Since the part of Bayreuth is "Altstadt" (but no one would write that down as part of the address - it is Geseeser Weg 1, 95447 Bayreuth) select that - shows correctly on the map
Let's try an example in Czeck Republic: Dukelská Ulica in Sokolov - Addresses - Spell Country: Ceská Republica - Spell City: Sokolov - No Results found but - Addresses - Spell Country: Country - Spell City: Sokolov - Enter Street name: Dukelská - Enter House Number: 1 - shows correctly on the map
I know that I can use command line parameters for mkgmap: --country-nameÞutschland ^ --country-abbrÞU ^ but that's not approriate here: there are 4 different countries to deal with. Otherwise, the parameters do their job correctly.
According to the documentation, the style file should help mkgmap determine the country, and both my lines and points files say on their top: include 'inc/address';
How to solve this problem? Thanks for your hints.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Meanwhile I did some experiments. With a fresh download from Geofabrik, I started with germany.osm.pbf without any additional modification by osmconvert. I split it, and created the map with the same parameters and style file. With the examples from Germany, I received the same results. Next, I removed the "include" sections from the style files and replaced them by the contents of the respective files. Same result. Next, I tried the default style (as of mkgmap 2724). Again, the same results. This means: it is not caused by a defect in my style file, nor in a defect in processing with osmconvert. Also a defect in resolving the include files can be excluded. Still, the data downloaded from Geofabrik could be defective. When I use the --country-name=Deutschland --country-abbr=DEU parameters, places are correctly found in Germany. The country "Country" is no more available. For small villages, the index is then OK. But for towns consisting of some quarters, it is still defective: there are no roads neither in Erlangen nor in Bayreuth, and the "Geseeser Weg" can only be found in "Altstadt" instead of Bayreuth. Next, I returned to mkgmap version 2654. I had to remove all lines with "admin_level" from relations, "capital" from points, the comparison of two values from lines. Also this did not solve the problem. That means, that the creation of the address index is broken somewhere in mkgmap.
Hello Bernhard, please read my previous mail which was sent to you only by mistake: ============= Hello Bernhard, you are including the inc/address file but you don't use the bounds paramter that links the precompiled bounds file. This is required to let the inc/address file work. Only using the bounds parameter the mkgmap:admin_levelN tags are assigned which are used by the inc/address file. You can download some precompiled bounds from http://www.navmaps.eu/boundaries Instead you are using --location-autofill=bounds,nearest. Bounds is no longer supported (but silently accepted). So the only address assigning algorithm is the location-autofill=nearest. This is a good guess only so don't expect good results. It's mainly used for regions that don't have a good boundary coverage. Have fun! WanMil
Meanwhile I did some experiments.
With a fresh download from Geofabrik, I started with germany.osm.pbf without any additional modification by osmconvert. I split it, and created the map with the same parameters and style file. With the examples from Germany, I received the same results.
Next, I removed the "include" sections from the style files and replaced them by the contents of the respective files. Same result.
Next, I tried the default style (as of mkgmap 2724). Again, the same results.
This means: it is not caused by a defect in my style file, nor in a defect in processing with osmconvert. Also a defect in resolving the include files can be excluded. Still, the data downloaded from Geofabrik could be defective.
When I use the --country-name=Deutschland --country-abbr=DEU parameters, places are correctly found in Germany. The country "Country" is no more available. For small villages, the index is then OK. But for towns consisting of some quarters, it is still defective: there are no roads neither in Erlangen nor in Bayreuth, and the "Geseeser Weg" can only be found in "Altstadt" instead of Bayreuth.
Next, I returned to mkgmap version 2654. I had to remove all lines with "admin_level" from relations, "capital" from points, the comparison of two values from lines. Also this did not solve the problem.
That means, that the creation of the address index is broken somewhere in mkgmap.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello Bernhard, some time ago I had the same trouble. Once I understood it, I have set up the wiki page: http://wiki.openstreetmap.org/wiki/Mkgmap/help/Tags Have a look at the notes [3] and [4] You will need precompiled bounds. Cheers Manfred Meanwhile I did some experiments. With a fresh download from Geofabrik, I started with germany.osm.pbf without any additional modification by osmconvert. I split it, and created the map with the same parameters and style file. With the examples from Germany, I received the same results. Next, I removed the "include" sections from the style files and replaced them by the contents of the respective files. Same result. Next, I tried the default style (as of mkgmap 2724). Again, the same results. This means: it is not caused by a defect in my style file, nor in a defect in processing with osmconvert. Also a defect in resolving the include files can be excluded. Still, the data downloaded from Geofabrik could be defective. When I use the --country-name=Deutschland --country-abbr=DEU parameters, places are correctly found in Germany. The country "Country" is no more available. For small villages, the index is then OK. But for towns consisting of some quarters, it is still defective: there are no roads neither in Erlangen nor in Bayreuth, and the "Geseeser Weg" can only be found in "Altstadt" instead of Bayreuth. Next, I returned to mkgmap version 2654. I had to remove all lines with "admin_level" from relations, "capital" from points, the comparison of two values from lines. Also this did not solve the problem. That means, that the creation of the address index is broken somewhere in mkgmap. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I have loaded my latest img made using 2800 of mkgmap and a custom style along with typ file on to a Garmin Rino 650. This unit has only ever had the OSM maps that I have created on it. The POI lookup has been causing me a few issues in the past with my 62S being much better but that might be due to it having Garmin's own Topo map loaded. I am at a loss how and what index from what img file my Garmins use. Anyway, the problem is nothing comes up when I select all POI so I went into geographical features and then water features to find a lake. No water features showed up. I then selected land features and then could find the lake that I was after. It appears that at least on the Rino 650 the POI index has issues. It the above a known problem with mkgmap or is their something wrong with my style and/or typ file? I use the following bat in Windows 7 to create the img. REM mkgmap command lineREM -------------------java -Xmx8192m -Xms2048m -ea -jar mkgmap.jar ^ --max-jobs ^ --gmapsupp ^ --route --drive-on-left --check-roundabouts ^ --generate-sea ^ --remove-ovm-work-files ^ --add-pois-to-areas ^ --location-autofill=nearest ^ --index ^ --style-file=styles\mapnik\ ^ --description="Ent_World 20M Contours" ^ --country-name=Australia --country-abbr=AU --region-name=Tasmania --region-abbr=TAS --draw-priority=25 Ent_World.osm.pbf ^ --family-name=contours --draw-priority=31 --transparent Ent_contours_20M\Ent_world*.osm.pbf ^ styles\mapnik\mapnik_play.typ Cheers Brett
Hi Time to follow up on this issue from some time back as I have not found any solutions. It would be good to have the index search feature refined. Anyway here is it again. Thanks for your consideration. I have loaded my latest img made using 2800 of mkgmap and a custom style along with typ file on to a Garmin Rino 650. This unit has only ever had the OSM maps that I have created on it. The POI lookup has been causing me a few issues in the past with my 62S being much better but that might be due to it having Garmin's own Topo map loaded. I am at a loss how and what index from what img file my Garmins use. Anyway, the problem is nothing comes up when I select all POI so I went into geographical features and then water features to find a lake. No water features showed up. I then selected land features and then could find the lake that I was after. It appears that at least on the Rino 650 the POI index has issues. It the above a known problem with mkgmap or is their something wrong with my style and/or typ file? I use the following bat in Windows 7 to create the img. REM mkgmap command line REM ------------------- java -Xmx8192m -Xms2048m -ea -jar mkgmap.jar ^ --max-jobs ^ --gmapsupp ^ --route --drive-on-left --check-roundabouts ^ --generate-sea ^ --remove-ovm-work-files ^ --add-pois-to-areas ^ --location-autofill=nearest ^ --index ^ --style-file=styles\mapnik\ ^ --description="Ent_World 20M Contours" ^ --country-name=Australia --country-abbr=AU --region-name=Tasmania --region-abbr=TAS --draw-priority=25 Ent_World.osm.pbf ^ --family-name=contours --draw-priority=31 --transparent Ent_contours_20M\Ent_world*.osm.pbf ^ styles\mapnik\mapnik_play.typ Cheers Brett
Hi Brett, an issue with the index on a Garmin device is that it requires specific codes for specific items. For a comparison of Garmin models and the use/appearance of codes, see http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types - In most cases, the meaning is the same for different models. In your command, you use --style-file=styles\mapnik\ ^ i.e. a relative path to the style, and a final backslash. Are you sure that the "correct" style was used (e.g. when you inspect your map with QLandkarte)? I use absolute path, without a final backslash, but that might be irrelevant. It is also my impression that Garmin uses all maps (even those which were switched off) when a POI search is performed - try to remove them as much as possible (I change the extension from *.IMG to *.IM) - I haven't tried that with the base map yet... Regards, Bernhard Am 24.11.2013 00:51, schrieb Brett Russell:
Hi
Time to follow up on this issue from some time back as I have not found any solutions. It would be good to have the index search feature refined. Anyway here is it again. Thanks for your consideration.
I have loaded my latest img made using 2800 of mkgmap and a custom style along with typ file on to a Garmin Rino 650. This unit has only ever had the OSM maps that I have created on it. The POI lookup has been causing me a few issues in the past with my 62S being much better but that might be due to it having Garmin's own Topo map loaded. I am at a loss how and what index from what img file my Garmins use.
Anyway, the problem is nothing comes up when I select all POI so I went into geographical features and then water features to find a lake. No water features showed up. I then selected land features and then could find the lake that I was after. It appears that at least on the Rino 650 the POI index has issues.
It the above a known problem with mkgmap or is their something wrong with my style and/or typ file? I use the following bat in Windows 7 to create the img.
REM mkgmap command line REM ------------------- java -Xmx8192m -Xms2048m -ea -jar mkgmap.jar ^ --max-jobs ^ --gmapsupp ^ --route --drive-on-left --check-roundabouts ^ --generate-sea ^ --remove-ovm-work-files ^ --add-pois-to-areas ^ --location-autofill=nearest ^ --index ^ --style-file=styles\mapnik\ ^ --description="Ent_World 20M Contours" ^ --country-name=Australia --country-abbr=AU --region-name=Tasmania --region-abbr=TAS --draw-priority=25 Ent_World.osm.pbf ^ --family-name=contours --draw-priority=31 --transparent Ent_contours_20M\Ent_world*.osm.pbf ^ styles\mapnik\mapnik_play.typ
Cheers
Brett
On Sun, Nov 24, Bernhard Hiller wrote:
It is also my impression that Garmin uses all maps (even those which were switched off) when a POI search is performed
Correct, Garmin uses always all maps, even if deaktivated. And depending on the firmware, it ignores the index and reads the POI directly from the img tiles. You can see that very nice if you compare the POIs of the same map on a 60CSx and a 62s. The 60CSx is twice faster and only shows POIs from the index, the 62s shows all POIs, even the ones not in the index. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Thanks for your hints. With the precompiled boundaries, the map of the European countries receives a functional address index. When creating a map of South-East Asia (Thailand, Malysia, Singapore, Cambodia, Vietnam, Indonesia, Laos), the address index does not work: no roads are found in Bangkok or Kuala Lumpur! Beyond the fact of the defectiveness with South East Asia, that procedure does not feel correct at all: it means that I have to get the same (?) data from two different locations in two different formats. Or even three, when using the --precompiled-sea option (which I never got working with South East Asia). All those files have different update schedules which means inconsistencies. With central Europe, those inconsistencies are not very likely, since borders and coast lines are available with high quality. That does not apply to South East Asia. Last week I updated some sections of the Thai-Malaysian border, and today of the South-Thai coast. I know that sometimes a correct solution may be very difficult, and wtf, let's take a shortcut with a "pragmatic" solution. How complicated is a "correct" solution here?
Hi Bernhard, Bernhard Hiller wrote
I know that sometimes a correct solution may be very difficult, and wtf, let's take a shortcut with a "pragmatic" solution. How complicated is a "correct" solution here?
you can search the archives to find out why these solutions are preferred. The main reason besides performance is that a part of the world doesn't contain complete sea and probably also not complete boundaries. If you like, you can compile your own boundaries data: http://wiki.openstreetmap.org/wiki/Mkgmap/help/options#Create_Preprocessed_B... see also http://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompile... Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Address-index-for-multi-country-map-tp5784034... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I know that sometimes a correct solution may be very difficult, and wtf, let's take a shortcut with a "pragmatic" solution. How complicated is a "correct" solution here?
A correct solution requires to have complete and error free boundary relations for the whole world...
participants (6)
-
Bernhard Hiller -
Brett Russell -
GerdP -
Manfred Brenneisen -
Thorsten Kukuk -
WanMil