[locator] Europe boundary data for download
The European boundaries now compiled with the correct osmosis settings are available for download: http://www.navmaps.eu/wanmil/europe_bounds_20110501.zip (136MB) Many thanks to Johan for providing the webspace! WanMil
On May 1, 2011, at 19:54, WanMil wrote:
The European boundaries now compiled with the correct osmosis settings are available for download:
With the new set of boundaries, I now get the following error in the log: 2011/05/01 21:37:31 SEVERE (BoundaryUtil): 94000003.osm.gz: Cannot load boundary file bounds/bounds_2100000_250000.bnd: java.io.UTFDataFormatException: malformed input around byte 346 It's now a different file, and a different byte. :-) Cheers.
Am 01.05.2011 21:48, schrieb Clinton Gladstone:
On May 1, 2011, at 19:54, WanMil wrote:
The European boundaries now compiled with the correct osmosis settings are available for download:
With the new set of boundaries, I now get the following error in the log:
2011/05/01 21:37:31 SEVERE (BoundaryUtil): 94000003.osm.gz: Cannot load boundary file bounds/bounds_2100000_250000.bnd: java.io.UTFDataFormatException: malformed input around byte 346
It's now a different file, and a different byte. :-)
Cheers.
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet reappeared. You may have caught the error here. Cheers.
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet reappeared.
You may have caught the error here.
Cheers.
Yes, you were quicker than me writing the email :-) I found the bug. The Java stream for reading the data has two skip methods (which is used to not read boundaries outside the tile bounds). One correct skip method and one incorrect. Now you can guess which one I used.... So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932. WanMil
The boundary-files have the same address (http://www.navmaps.eu/wanmil/europe_bounds_20110501.zip)?! And can you please provide logging.properties-file which I need to log the LocationHook. I've never done this before, I've tried it but I still get an empty logfile. Some other questions: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN And mkgmap ask for some boundary files, which seems not to exist, but I downloaded the whole zip-file: SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_300000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_300000.bnd (No such file or directory) Cheers Martin Am 02.05.2011 um 21:46 schrieb WanMil:
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet reappeared.
You may have caught the error here.
Cheers.
Yes, you were quicker than me writing the email :-) I found the bug. The Java stream for reading the data has two skip methods (which is used to not read boundaries outside the tile bounds). One correct skip method and one incorrect. Now you can guess which one I used....
So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The boundary-files have the same address (http://www.navmaps.eu/wanmil/europe_bounds_20110501.zip)?!
Yes, they haven't changed because just the code to read them were buggy.
And can you please provide logging.properties-file which I need to log the LocationHook. I've never done this before, I've tried it but I still get an empty logfile.
Look into the wiki: http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging You have to add the line uk.me.parabola.mkgmap.reader.osm.LocationHook.level=FINE to get all log messages from the LocationHook.
Some other questions: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN
I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes.
And mkgmap ask for some boundary files, which seems not to exist, but I downloaded the whole zip-file: SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_300000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_300000.bnd (No such file or directory)
I know that. I haven't checked that but possibly these boundary tiles may contain no boundary at all (sea area?!?). I have to check that later on. WanMil
Cheers Martin
Am 02.05.2011 um 21:46 schrieb WanMil:
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet reappeared.
You may have caught the error here.
Cheers.
Yes, you were quicker than me writing the email :-) I found the bug. The Java stream for reading the data has two skip methods (which is used to not read boundaries outside the tile bounds). One correct skip method and one incorrect. Now you can guess which one I used....
So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932.
WanMil
Hi WanMil you did a very, very fine job on the locator and especially with this version 1935. In my opinion it's only a short time now before the locator branch is to be integrated into the core. Cities ánd streets which I couldn't find using version 1930 can now be found in the Garmin index. One finetuning question: is it possible to differ the style settings per country for multicountry maps (e.g. for the Netherlands admin_level 10 needs to be first in line, in Belgium and Luxembourg admin_level 8 needs to be first in line in order to prevent areas of a town to appear as the complete city) Cheers, Johan By the way, i'm using.. mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } 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!=* & mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' } mkgmap:postal_code!=* & openGeoDB:postal_codes=* { set mkgmap:postal_code='${openGeoDB:postal_codes}' } mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postalcode}' } ..as my preferred settings now, because it produces the -in my opinion- best index for multicountry maps On Mon, 02 May 2011 22:33:58 +0200, WanMil <wmgcnfg@web.de> wrote:
The boundary-files have the same address (http://www.navmaps.eu/wanmil/europe_bounds_20110501.zip)?!
Yes, they haven't changed because just the code to read them were buggy.
And can you please provide logging.properties-file which I need to log the LocationHook. I've never done this before, I've tried it but I still get an empty logfile.
Look into the wiki: http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging You have to add the line uk.me.parabola.mkgmap.reader.osm.LocationHook.level=FINE to get all log messages from the LocationHook.
Some other questions: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN
I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes.
And mkgmap ask for some boundary files, which seems not to exist, but I downloaded the whole zip-file: SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_300000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_300000.bnd (No such file or directory)
I know that. I haven't checked that but possibly these boundary tiles may contain no boundary at all (sea area?!?). I have to check that later on.
WanMil
Cheers Martin
Am 02.05.2011 um 21:46 schrieb WanMil:
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet reappeared.
You may have caught the error here.
Cheers.
Yes, you were quicker than me writing the email :-) I found the bug. The Java stream for reading the data has two skip methods (which is used to not read boundaries outside the tile bounds). One correct skip method and one incorrect. Now you can guess which one I used....
So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Cool, r1935 solved a lot of issues, I see a lot of streetnames now that are located to places. On the nuvi 310 and on the Dakota this seem to work. Congratulations and thanks Wanmil! About the finetuning per country, you could try some regular expression: mkgmap:admin_level2 ~ '\bN\w*\b' which means everything that starts with N will match Do'nt know if this will work, I have to test it for the Benelux: mkgmap:city!=* & mkgmap:admin_level2 ~ '\bN\w*\b'& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level2 ~ '\bB\w*\b'& mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level2 ~ '\bD\w*\b'& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level2 ~ '\bL\w*\b'& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } In Belgium the streetnames are in level 9 I think? Waht about regions, In Belgium Provinces seem to be in either 5 or 6 (depending if its in Vlaanderen or Wallonie?) In the Netherlands in 4.
Johan, mkgmap:admin_level2, is_in:country and addr:country are all normalized to the three letter country code defined in the LocatorConfig.xml. So you can tweek your rules for the Netherlands by adding the rule mkgmap:country="NLD": mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country="NLD" & mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' } etc. WanMil
Hi WanMil
you did a very, very fine job on the locator and especially with this version 1935. In my opinion it's only a short time now before the locator branch is to be integrated into the core. Cities ánd streets which I couldn't find using version 1930 can now be found in the Garmin index.
One finetuning question: is it possible to differ the style settings per country for multicountry maps (e.g. for the Netherlands admin_level 10 needs to be first in line, in Belgium and Luxembourg admin_level 8 needs to be first in line in order to prevent areas of a town to appear as the complete city)
Cheers, Johan
By the way, i'm using..
mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
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!=*& mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:postal_code!=*& addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' } mkgmap:postal_code!=*& openGeoDB:postal_codes=* { set mkgmap:postal_code='${openGeoDB:postal_codes}' } mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postalcode}' }
..as my preferred settings now, because it produces the -in my opinion- best index for multicountry maps
On Mon, 02 May 2011 22:33:58 +0200, WanMil<wmgcnfg@web.de> wrote:
The boundary-files have the same address (http://www.navmaps.eu/wanmil/europe_bounds_20110501.zip)?!
Yes, they haven't changed because just the code to read them were buggy.
And can you please provide logging.properties-file which I need to log the LocationHook. I've never done this before, I've tried it but I still get an empty logfile.
Look into the wiki: http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging You have to add the line uk.me.parabola.mkgmap.reader.osm.LocationHook.level=FINE to get all log messages from the LocationHook.
Some other questions: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN
I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes.
And mkgmap ask for some boundary files, which seems not to exist, but I downloaded the whole zip-file: SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2550000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2550000_300000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_250000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_250000.bnd (No such file or directory) SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz: Cannot load boundary file bounds/bounds_2600000_300000.bnd: java.io.FileNotFoundException: bounds/bounds_2600000_300000.bnd (No such file or directory)
I know that. I haven't checked that but possibly these boundary tiles may contain no boundary at all (sea area?!?). I have to check that later on.
WanMil
Cheers Martin
Am 02.05.2011 um 21:46 schrieb WanMil:
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet reappeared.
You may have caught the error here.
Cheers.
Yes, you were quicker than me writing the email :-) I found the bug. The Java stream for reading the data has two skip methods (which is used to not read boundaries outside the tile bounds). One correct skip method and one incorrect. Now you can guess which one I used....
So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM
El 03/05/11 13:40, Carlos Dávila escribió:
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the "Highway X has no region (define a default region to zap this warning)"? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref.
El 03/05/11 13:40, Carlos Dávila escribió:
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the "Highway X has no region (define a default region to zap this warning)"? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref.
I don't understand what you are talking about. Please be more specific what your problem is. WanMil
El 03/05/11 17:54, WanMil escribió:
El 03/05/11 13:40, Carlos Dávila escribió:
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the "Highway X has no region (define a default region to zap this warning)"? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. Perhaps I did a wrong guess, but I supposed region for any highway should be supplied by the new locator algorithm. If that's right, the warning implies the affected way falls within an area not covered by any boundary polygon. So I would like to be able to locate that way to search why there is no boundary for that area.
El 03/05/11 17:54, WanMil escribió:
El 03/05/11 13:40, Carlos Dávila escribió:
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the "Highway X has no region (define a default region to zap this warning)"? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. Perhaps I did a wrong guess, but I supposed region for any highway should be supplied by the new locator algorithm. If that's right, the warning implies the affected way falls within an area not covered by any boundary polygon. So I would like to be able to locate that way to search why there is no boundary for that area.
Please provide the excat error message and your complete mkgmap options and your mkgmap version. WanMil
El 03/05/11 18:24, WanMil escribió:
El 03/05/11 17:54, WanMil escribió:
El 03/05/11 13:40, Carlos Dávila escribió:
El 02/05/11 22:33, WanMil escribió:
> Do somebody know, what this error means: > Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the "Highway X has no region (define a default region to zap this warning)"? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. Perhaps I did a wrong guess, but I supposed region for any highway should be supplied by the new locator algorithm. If that's right, the warning implies the affected way falls within an area not covered by any boundary polygon. So I would like to be able to locate that way to search why there is no boundary for that area. Please provide the excat error message just a few ones: 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway CV-35 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway A-3 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway A-7 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway Ma-13 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway AP-7 has no region (define a default region to zap this warning) and your complete mkgmap options java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=boundaries-peninsula.osm --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=39 --product-id=1 --series-name="OSM-España-index" --index --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio -c spain.args and your mkgmap version. r1935
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM
Don't know. I have to check that. WanMil
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM
I have compiled spain with a geofabrik dump of today and did not get this error message. WanMil
El 03/05/11 18:25, WanMil escribió:
El 02/05/11 22:33, WanMil escribió:
Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but "Gibraltar / United Kingdom" is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM I have compiled spain with a geofabrik dump of today and did not get this error message. I got it with the same mkgmap version and parameters sent in my previous mail
On May 2, 2011, at 21:46, WanMil wrote:
So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932.
So far my tests with r1935 have been quite good. I do have one issue though: when I send the maps to a GPS device (Nüvi or eTrex), if there are several towns with the same same, the GPS device will only list one. Example: Walldorf in Germany. There is a Walldorf in Gross-Gerau, Rhein-Neckar-Kreis, and Schmalkalden-Meiningen. The GPS allows only Walldorf, Schmalkalden-Meiningen to be selected. The streets of the "other" Walldorf seem to be listed under this Walldorf, but the GPS cannot display them on the map. - The addresses are found correctly using Basecamp for Mac OS. - I send the maps to my devices using Garmin's MapInstall for Mac OS. Can anyone reproduce this? Cheers.
I have found a similar issue with the village of Achterveld, which boundaries lies in two Provinces: http://www.openstreetmap.org/browse/relation/302103 http://www.openstreetmap.org/browse/relation/310003 Only Achterveld in the province of Gelderland is listed on the device. Streets in Achterveld, Gelderland can be found and located, the other streets (in the center of the village for example, province Utrecht) are only listed but no loaction can be found on the GPS. In Mapsource everything works fine. Maybe a good test case to debug? ---------- Clinton wrote: On May 2, 2011, at 21:46, WanMil wrote:
So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932.
So far my tests with r1935 have been quite good. I do have one issue though: when I send the maps to a GPS device (Nüvi or eTrex), if there are several towns with the same same, the GPS device will only list one. Example: Walldorf in Germany. There is a Walldorf in Gross-Gerau, Rhein-Neckar-Kreis, and Schmalkalden-Meiningen. The GPS allows only Walldorf, Schmalkalden-Meiningen to be selected. The streets of the "other" Walldorf seem to be listed under this Walldorf, but the GPS cannot display them on the map. - The addresses are found correctly using Basecamp for Mac OS. - I send the maps to my devices using Garmin's MapInstall for Mac OS. Can anyone reproduce this? Cheers.
Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 They belong to bounds_2300000_250000.bnd but if I run the gpx converter they are not in it. And maybe add België as variant to the locator LocatorConfig.xml, as well as België - Belgique - Belgien
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711
They belong to bounds_2300000_250000.bnd but if I run the gpx converter they are not in it.
And maybe add België as variant to the locator LocatorConfig.xml, as well as België - Belgique - Belgien
To detect such holes automatically it would be very useful to have a tool which reads the bounds file (this is already implemented) and calculates the uncovered areas for each admin level (this has to be done but is not very difficult to implement). Anybody out there who is willing to do this? I have a lot of other things to do and this would help to speed up the development. WanMil
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/106888874 is overlapping with http://www.openstreetmap.org/browse/way/106888875 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed). You need to correct it and two days later I can recompile the boundary tiles. WanMil
I'm sorry, i'm not familiar with those complex border relations, maybe someone out there can fix it? ---------- "WanMil" wrote:
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/106888874 is overlapping with http://www.openstreetmap.org/browse/way/106888875 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed). You need to correct it and two days later I can recompile the boundary tiles. WanMil
Am 04.05.2011 18:40, schrieb WanMil:
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/106888874 is overlapping with http://www.openstreetmap.org/browse/way/106888875 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed).
and with http://www.openstreetmap.org/browse/way/106888876 For me 106888875 and the other two can be deleted. Josef
You need to correct it and two days later I can recompile the boundary tiles.
-- PGP Schlüssel: 311D1055 http://keyserver.pgp.com
Am 04.05.2011 19:19, schrieb Josef Latt:
Am 04.05.2011 18:40, schrieb WanMil:
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/106888874 is overlapping with http://www.openstreetmap.org/browse/way/106888875 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed).
and with http://www.openstreetmap.org/browse/way/106888876
For me 106888875 and the other two can be deleted.
And many relations must be checked. Not so easy.
Josef
You need to correct it and two days later I can recompile the boundary tiles.
-- PGP Schlüssel: 311D1055 http://keyserver.pgp.com
The Luxembourg country border been fixed in JOSM (nice to have validator around!). However, still some validator errors for the France border relations. Hopefully some French mappers step in to update these borders. Cheers Johan On Wed, 04 May 2011 19:32:07 +0200, Josef Latt <Josef.Latt@gmx.net> wrote:
Am 04.05.2011 19:19, schrieb Josef Latt:
Am 04.05.2011 18:40, schrieb WanMil:
Another issue:
The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711
The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/106888874 is overlapping with http://www.openstreetmap.org/browse/way/106888875 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed).
and with http://www.openstreetmap.org/browse/way/106888876
For me 106888875 and the other two can be deleted.
And many relations must be checked. Not so easy.
Josef
You need to correct it and two days later I can recompile the boundary tiles.
Will there be a new European boundary data available for download and how will this work out later if the locator is merged to trunk? Maybe geofabrik will be willing to host and compile this regularly next to the country data? ---------- "navmaps" wrote The Luxembourg country border been fixed in JOSM (nice to have validator around!). However, still some validator errors for the France border relations. Hopefully some French mappers step in to update these borders. Cheers Johan
I have tried to compile a Europe bounds set but still get stuck on the first step. Somehow I can't write the results to a pbf or osm file. My osmosis options are: set OSMOSIS_OPTIONS=--read-pbf c:\downloads\europe.osm.pbf --bounding-box bottom=41 left=-6 top=57 right=16 --tf accept-ways boundary=administrative --used-node --write-pbf bways.osm.pbf I'm using osmosis v0.39, OS is windows vista 32 bits This results after a few hours in a bways.osm.pbf of 130 bytes :-( Will there be a new European bounds file available soon?
I have managed (with the help of OSMembrane) to put the whole osmosis steps into one command: osmosis.bat ^ --read-pbf file=europe.osm.pbf outPipe.0=1 ^ --tee 2 inPipe.0=1 outPipe.0=2 outPipe.1=3 ^ --buffer inPipe.0=3 outPipe.0=4 ^ --buffer inPipe.0=2 outPipe.0=5 ^ --tag-filter accept-relations boundary=administrative inPipe.0=4 outPipe.0=6 ^ --used-way inPipe.0=6 outPipe.0=7 ^ --tag-filter reject-relations inPipe.0=5 outPipe.0=8 ^ --tag-filter accept-ways boundary=administrative inPipe.0=8 outPipe.0=9 ^ --used-node inPipe.0=9 outPipe.0=10 ^ --used-node inPipe.0=7 outPipe.0=11 ^ --merge inPipe.0=10 inPipe.1=11 outPipe.0=12 ^ --write-pbf file=europe-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12 Anyhow processing of whole europe takes a very long time and the pbf file is growing only within the last minutes. You can check the ongoing osmosis processing in the directory C:\Users\<username>\AppData\Local\Temp (Win7). Osmosis creates files named afnd*.tmp, afwy*.tmp and afrl*.tmp that are constantly getting larger during processing. I think I will recreate the european bounds during the next days and will commit some additional useful debug tools for these files. WanMil
I have tried to compile a Europe bounds set but still get stuck on the first step. Somehow I can't write the results to a pbf or osm file. My osmosis options are:
set OSMOSIS_OPTIONS=--read-pbf c:\downloads\europe.osm.pbf --bounding-box bottom=41 left=-6 top=57 right=16 --tf accept-ways boundary=administrative --used-node --write-pbf bways.osm.pbf
I'm using osmosis v0.39, OS is windows vista 32 bits
This results after a few hours in a bways.osm.pbf of 130 bytes :-(
Will there be a new European bounds file available soon? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
A few days ago I tried --rb file=d:\europe.osm.pbf --tf accept-ways boundary=administrative --used-node --write-xml file=d:\mkgmap-europe-boundaries.osm Thus I created 1.508 bounds files and a workable map (still a few problems finding cities and streets through cities -> selects streets, but the bypass to select all streets works for these incidental problems). I'm looking forward to Wanmils update and debug tools! Cheers Johan On Thu, 12 May 2011 19:53:00 +0200, WanMil wrote:
I have managed (with the help of OSMembrane) to put the whole osmosis steps into one command:
osmosis.bat ^ --read-pbf file=europe.osm.pbf outPipe.0=1 ^ --tee 2 inPipe.0=1 outPipe.0=2 outPipe.1=3 ^ --buffer inPipe.0=3 outPipe.0=4 ^ --buffer inPipe.0=2 outPipe.0=5 ^ --tag-filter accept-relations boundary=administrative inPipe.0=4 outPipe.0=6 ^ --used-way inPipe.0=6 outPipe.0=7 ^ --tag-filter reject-relations inPipe.0=5 outPipe.0=8 ^ --tag-filter accept-ways boundary=administrative inPipe.0=8 outPipe.0=9 ^ --used-node inPipe.0=9 outPipe.0=10 ^ --used-node inPipe.0=7 outPipe.0=11 ^ --merge inPipe.0=10 inPipe.1=11 outPipe.0=12 ^ --write-pbf file=europe-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
Anyhow processing of whole europe takes a very long time and the pbf file is growing only within the last minutes. You can check the ongoing osmosis processing in the directory C:\Users\<username>\AppData\Local\Temp (Win7). Osmosis creates files named afnd*.tmp, afwy*.tmp and afrl*.tmp that are constantly getting larger during processing.
I think I will recreate the european bounds during the next days and will commit some additional useful debug tools for these files.
WanMil
I have tried to compile a Europe bounds set but still get stuck on the first step. Somehow I can't write the results to a pbf or osm file. My osmosis options are:
set OSMOSIS_OPTIONS=--read-pbf c:\downloads\europe.osm.pbf --bounding-box bottom=41 left=-6 top=57 right=16 --tf accept-ways boundary=administrative --used-node --write-pbf bways.osm.pbf
I'm using osmosis v0.39, OS is windows vista 32 bits
This results after a few hours in a bways.osm.pbf of 130 bytes :-(
Will there be a new European bounds file available soon? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I have found a 4gb file named afnd*.tmp in the users temp directory, but somehow osmosis can't save these temp files after the process. I'm also looking forward to Wanmils updates!
I have found a 4gb file named afnd*.tmp in the users temp directory, but somehow osmosis can't save these temp files after the process. I'm also looking forward to Wanmils updates!
Osmosis creates 3 afnd*.tmp with size > 6GB for the current europe dump using my parameters. So when you find a 4gb file you have a long way to go.... ;-( My (rather new) laptop uses around 3 hours for extracting the boundaries from the europe dump. WanMil
Hello WanMil, I'm guessing you've already created the new bound files with your new settings?! Where can I download them? Cheers Martin Am 13.05.2011 um 19:02 schrieb WanMil:
I have found a 4gb file named afnd*.tmp in the users temp directory, but somehow osmosis can't save these temp files after the process. I'm also looking forward to Wanmils updates!
Osmosis creates 3 afnd*.tmp with size > 6GB for the current europe dump using my parameters. So when you find a 4gb file you have a long way to go.... ;-(
My (rather new) laptop uses around 3 hours for extracting the boundaries from the europe dump.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I am not an osmosis expert but I guess that you loose a fair amount of boundaries with your parameters. All ways that are not tagged with boundary=administrative but are used in a boundary relation should be missing in your osm file. WanMil
A few days ago I tried --rb file=d:\europe.osm.pbf --tf accept-ways boundary=administrative --used-node --write-xml file=d:\mkgmap-europe-boundaries.osm
Thus I created 1.508 bounds files and a workable map (still a few problems finding cities and streets through cities -> selects streets, but the bypass to select all streets works for these incidental problems). I'm looking forward to Wanmils update and debug tools!
Cheers Johan
On Thu, 12 May 2011 19:53:00 +0200, WanMil wrote:
I have managed (with the help of OSMembrane) to put the whole osmosis steps into one command:
osmosis.bat ^ --read-pbf file=europe.osm.pbf outPipe.0=1 ^ --tee 2 inPipe.0=1 outPipe.0=2 outPipe.1=3 ^ --buffer inPipe.0=3 outPipe.0=4 ^ --buffer inPipe.0=2 outPipe.0=5 ^ --tag-filter accept-relations boundary=administrative inPipe.0=4 outPipe.0=6 ^ --used-way inPipe.0=6 outPipe.0=7 ^ --tag-filter reject-relations inPipe.0=5 outPipe.0=8 ^ --tag-filter accept-ways boundary=administrative inPipe.0=8 outPipe.0=9 ^ --used-node inPipe.0=9 outPipe.0=10 ^ --used-node inPipe.0=7 outPipe.0=11 ^ --merge inPipe.0=10 inPipe.1=11 outPipe.0=12 ^ --write-pbf file=europe-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
Anyhow processing of whole europe takes a very long time and the pbf file is growing only within the last minutes. You can check the ongoing osmosis processing in the directory C:\Users\<username>\AppData\Local\Temp (Win7). Osmosis creates files named afnd*.tmp, afwy*.tmp and afrl*.tmp that are constantly getting larger during processing.
I think I will recreate the european bounds during the next days and will commit some additional useful debug tools for these files.
WanMil
I have tried to compile a Europe bounds set but still get stuck on the first step. Somehow I can't write the results to a pbf or osm file. My osmosis options are:
set OSMOSIS_OPTIONS=--read-pbf c:\downloads\europe.osm.pbf --bounding-box bottom=41 left=-6 top=57 right=16 --tf accept-ways boundary=administrative --used-node --write-pbf bways.osm.pbf
I'm using osmosis v0.39, OS is windows vista 32 bits
This results after a few hours in a bways.osm.pbf of 130 bytes :-(
Will there be a new European bounds file available soon? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, I may be wrong but somehow I think that those streets are the streets that have streetnames who are found in several cities. Like "Main street" you have in places A, B C etc. If this is the case, my GPS (Dakota) cannot locate Main street if I enter place A to look for Main street. If I bypass to select all streets, I find a list with Main street in A, B and C and can locate it. ---------- Johan wrote: Thus I created 1.508 bounds files and a workable map (still a few problems finding cities and streets through cities -> selects streets, but the bypass to select all streets works for these incidental problems). I'm looking forward to Wanmils update and debug tools! Cheers Johan
participants (7)
-
Carlos Dávila -
Clinton Gladstone -
Josef Latt -
Martin -
Minko -
navmaps -
WanMil