[locator] Separate boundary files
I have committed changes to the locator branch which implements the usage of separate precompiled splitted boundary files. How does it work? * 1st step: Extract the boundary data Download an osm dump (e.g. the europe extract from geobfabrik). Extract the boundary data using osmosis: osmosis --rb europe.osm.pbf -tf accept-ways boundary=admistrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm (Maybe the osmosis parameters must be tuned to get *all* boundary data but I haven't investigated very long. Please send proposals how to improve it) * 2nd step: Start mkgmap with additional --createboundsfile option e.g. java -jar mkgmap.jar --createboundsfile=europe-boundaries.osm <... your other options ...> Before compiling the common tiles mkgmap reads the europe-boundaries.osm file, performs the multipolygon processing on it and saves special precompiled boundary tiles to the subdirectory bounds. The subdirectory can be changed by adding the new option --boundsdirectory=<directory> It is possible to precompile whole europe with less then 3GB main memory. The europe boundary tiles need around 330MB (bzip2 compressed ~120MB). * 3rd step: Use the precompiled boundary files After precompiling the bounds directory contains several "bounds_<lat>_<lon>.bnd" tile files. These are loaded and used automatically by the LocationHook. You need to compile the boundary tiles once only. Important: The LocationHook does no longer use the boundary information from the tiles. You need the precompiled boundary tiles. I have decided to go this way because I do not expect that splitter will be able to save tiles with complete multipolygons within a foreseeable period of time. WanMil
On Apr 25, 2011, at 19:21, WanMil wrote:
I have committed changes to the locator branch which implements the usage of separate precompiled splitted boundary files.
This seems like a quite plausible approach. I'll try it out. By the way, for others who attempt this, there were a few typos in WanMil's original osmosis command line. The following seems to be working for me: osmosis --rb europe.osm.pbf --tf accept-ways boundary=admistrative --tf accept-relations boundary=administrative --used-node --wx europe-boundaries.osm Cheers.
On 25.04.2011 23:06, Clinton Gladstone wrote:
On Apr 25, 2011, at 19:21, WanMil wrote:
I have committed changes to the locator branch which implements the usage of separate precompiled splitted boundary files. This seems like a quite plausible approach. I'll try it out.
By the way, for others who attempt this, there were a few typos in WanMil's original osmosis command line. The following seems to be working for me:
osmosis --rb europe.osm.pbf --tf accept-ways boundary=admistrative --tf accept-relations boundary=administrative --used-node --wx europe-boundaries.osm
Could someone just upload the boundaries after extracting them - (without any other need than CCBYSA 2.0 Openstreetmap & Contributors, so that using them needs no separate mention). Is this only for country boundaries, or also relevant for all other boundaries like states, cities and so on..
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I think it would be great, to have a wiki page, with some explanations, what to do for creating addressindex with locator-branch. Which parameters should I use? What to write in style-file? etc. I would do it myself, but I don't know, what have to be done. Henning
Henning, here my explanation in short (you may expand it and add some useful hints): 1. Download the locator branch 2. The style file must be complemented with some special address rules. Have a look at this post (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010656.html) how it works. The default style contains some basic rules. 3. You need precompiled boundary tiles. To create them you need an OSM file that should contain boundary information of an area that covers more than the tiles you want to use for your map. It doesn't hurt if it contains more than boundary information but that needs more memory. You can create such a file e.g. with osmosis: osmosis --rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm The precompile boundary tiles are created before the usual map compiling when you add the option --createboundsfile=europe-boundaries.osm to your mkgmap command line. The files are put to the subdirectory bounds if you don't set the option --boundsdirectory=<directory>. The precompilation must be performed once only. If you are happy with them and you get satisfying results you never have to do this step again. 4. Add the index option to your usual mkgmap command line. The precompiled tiles are used to retrieve the location information. So in short: After having split the boundary OSM file you need to call mkgmap: java -jar mkgmap.jar --createboundsfile=europe-boundary.osm --index <... your other mkgmap options ...> data/*.osm.gz At the next run you should remove the createboundsfile option. WanMil
Hi
I think it would be great, to have a wiki page, with some explanations, what to do for creating addressindex with locator-branch. Which parameters should I use? What to write in style-file? etc.
I would do it myself, but I don't know, what have to be done.
Henning
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
How do I run osmosis in a windows batch file? If I put this line in the osmosis.bat file: set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm I get this error: only one default (un-named) argument can exist per task. Arguments 3 and 2 have no name
This is a copy of my windows Bat file. Hope it helps. bin\osmosis.bat -v --rx -b50000 enableDateParsing=no file=planet.new.osm.gz --bb top=-6 left=107.1 bottom=-48 right=163.5 completeWays=yes completeRelations=yes --wx -bc50000 file=o:\garmin\splitter\Australia.osm Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Minko Sent: Wednesday, 27 April 2011 7:31 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] [locator] Separate boundary files How do I run osmosis in a windows batch file? If I put this line in the osmosis.bat file: set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm I get this error: only one default (un-named) argument can exist per task. Arguments 3 and 2 have no name _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
You need to - infront of tf. --tf instead of -tf ;) Henning Am 27.04.2011 12:01, schrieb Minko:
How do I run osmosis in a windows batch file? If I put this line in the osmosis.bat file:
set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm
I get this error: only one default (un-named) argument can exist per task. Arguments 3 and 2 have no name _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Henning, Probably in front of wx as well, otherwise I got an error again. Now it's running. set OSMOSIS_OPTIONS=--rb europe.osm.pbf --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --wx europe-boundaries.osm
Thanks WanMil, just two questions are left: What about location-autofil and index? Are they needed both or just index? Is it possible to input boundary-file as pbf? Henning
Thanks WanMil, just two questions are left:
What about location-autofil and index? Are they needed both or just index?
index is required. location-autofill should be set to 0.
Is it possible to input boundary-file as pbf?
Not yet, but that's easy to implement so I will add it soon. WanMil
Henning
Just run a small test, if I dont specify boundsdirectory, mkgmap complains about no boundary directory found. I got a few 'file not found messages' but I think they were caused by the fact that I ran osmosis with a bounding box that was too small (didnt want to process whole europe). The first results look very good. Seems that with this method a lot of issues are solved, like places are now in the correct Province and Country, and streets that once had no assigned place name can now be located. Thanks Wanmil, you have done an excellent job!
Just run a small test, if I dont specify boundsdirectory, mkgmap complains about no boundary directory found. I got a few 'file not found messages' but I think they were caused by the fact that I ran osmosis with a bounding box that was too small (didnt want to process whole europe). The first results look very good. Seems that with this method a lot of issues are solved, like places are now in the correct Province and Country, and streets that once had no assigned place name can now be located. Thanks Wanmil, you have done an excellent job!
Your results sounds fine! What do you say about performance? I was a bit disappointed about memory consumption and processing time. This has to be investigated and improved. I will have a look on your boundsdirectory error message. I would not expect it if you put the files in a subdirectory named bounds. But I didn't test it and the code is still in a prototype stage. So lot's of things to do :-) WanMil
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times. The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it.
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it.
I could upload the data for whole europe. Does anyone has a server where we can put it? WanMil
How big is it? On Thu, 28 Apr 2011 23:52:15 +0400, mkgmap-dev-bounces@lists.mkgmap.org.uk wrote:
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it.
I could upload the data for whole europe. Does anyone has a server where we can put it?
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
It's 117MB in one zip file.
How big is it? On Thu, 28 Apr 2011 23:52:15 +0400, mkgmap-dev-bounces@lists.mkgmap.org.uk wrote:
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it.
I could upload the data for whole europe. Does anyone has a server where we can put it?
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 28/04/11 22:40, WanMil escribió:
It's 117MB in one zip file.
How big is it? On Thu, 28 Apr 2011 23:52:15 +0400, mkgmap-dev-bounces@lists.mkgmap.org.uk wrote:
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it. I could upload the data for whole europe. Does anyone has a server where we can put it? I could host them at the same server I use for my maps (http://mapas.alternativaslibres.es)
Wanmil, you could send it to me and I can put it online on the openstreetmap.nl server. I've tried a bigger bounding box but after a few hours the osmosis process finishes and doesn't seem to save a europe-boundaries.osm file. Only if I use a smaller bounding box (around the Benelux area) it saves an osm file of 230 MB. I have tried to save it as bz2 too, but it doesnt help. The osmosis options are: set OSMOSIS_OPTIONS=--rb c:\downloads\europe.osm.pbf --bounding-box bottom=41 left=-6 top=57 right=16 --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --wx europe-boundaries.osm.bz2 I've used osmosis 0.39 I have compiled a few more tiles but some results were not so good. For instance all streets in this place (Etten-Leur) could not matched with the placename http://www.openstreetmap.org/browse/relation/297049 On the other hand all streets in for instance this place Leusden, could be matched with the placename: http://www.openstreetmap.org/browse/relation/310002 Both places don't have differences in tagging, and both places are in the centre of the tile, not on the edge. I have searched in the europe-boundaries.osm file and both relations are in this file. I also noticed some warnings like: Ccode == null name == Belgi# - belgique - belgien What does that mean?
Has anybody already uploaded the file? Martin On 28.04.2011 21:52, WanMil wrote:
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it. I could upload the data for whole europe. Does anyone has a server where we can put it?
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 2011-04-29 14:37, Martin wrote:
Has anybody already uploaded the file?
Martin
An older (november 2010) coastline extract from the Planet dump is here: http://planetosm.oxilion.nl/~lambertus/coastline.osm.gz
On 28/04/11 20:52, WanMil wrote:
With a boundsdirectory it went fine. I haven't paid attention to the performance, with a few tiles it was ok I guess. I'll try to compile the whole Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it.
I could upload the data for whole europe. Does anyone has a server where we can put it?
It could also be put on mkgmap.org, just upload it via files.mkgmap.org.uk and I can move it somewhere else. ..Steve
These are the results of my first (limited) tests: The list of places under State/Province field in MapSource "Search places" includes a lot more wrong places than without the boundary precompilation (locator r1922). For example I get State/Province "La Zubia" (from relation 347255) and place "Cumbres Verdes (node 1107558640), LA ZUBIA, ESP" under it. In the last days I've been correcting incomplete boundary polygons from mkgmap log. Searching for a random street (Calle Calvario) that exists within one of these multipolygons I fixed yesterday (relation 346527) I get the following: Trunk+spain.osm.pbf 28/4-> 46 "Calle Calvario" matches with complete city, region, country information (e.g. way 62120822: Calle Calvario, Alburquerque, EXTREMADURA, ESP) Locator r1925+spain.osm.pbf 27/4 -> 39 matches most of them with incomplete or even wrong city, region, country information (e.g. way 62120822: Calle Calvario, CÁCERES (should be BADAJOZ), ESP). Cáceres is relation 349018 and Badajoz 348994. Locator r1925+spain.osm.pbf 28/4 -> same result. Note mkgmap didn't complain about mp 346527. The boundary tiles are extracted daily from the same pbf file than map. My locator related styles: mkgmap:country!=* & addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=* & is_in:country=* { set mkgmap:country='${is_in:country}' } mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:region!=* & is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=* & mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=* & mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' } mkgmap:city!=* & openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' } 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: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}' } My commands: osmosis --read-pbf file="spain.osm.pbf" --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --write-xml file="spain-boundaries.osm" time /usr/lib/jvm/java-6-sun/bin/java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=spain-boundaries.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
Carlos, thanks for your reports. I cannot check your examples in detail now but I can give you some general hints. The current locator branch relies on complete boundaries. The word complete is important. The boundary precompilation algorithm does not automatically close multipolygons which are open and which has a loose endpoints out of the tile borders. This is necessary because one major reason for using precompiled data is that I want to get rid of wrong autoclosed boundaries. (Please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010797.html where I tried to explain the problem more in detail). If you use a dump of spain only you might loose some of the boundaries that are located on the border. I would recommend to download a larger dump and cut out a larger area than spain for boundary precompilation (e.g. spain + 10km around). Of course the changes are not tested very well and there are tons of bugs in it. I'll have to implement some checks to see if the precompilation really works well. WanMil
These are the results of my first (limited) tests: The list of places under State/Province field in MapSource "Search places" includes a lot more wrong places than without the boundary precompilation (locator r1922). For example I get State/Province "La Zubia" (from relation 347255) and place "Cumbres Verdes (node 1107558640), LA ZUBIA, ESP" under it. In the last days I've been correcting incomplete boundary polygons from mkgmap log. Searching for a random street (Calle Calvario) that exists within one of these multipolygons I fixed yesterday (relation 346527) I get the following: Trunk+spain.osm.pbf 28/4-> 46 "Calle Calvario" matches with complete city, region, country information (e.g. way 62120822: Calle Calvario, Alburquerque, EXTREMADURA, ESP) Locator r1925+spain.osm.pbf 27/4 -> 39 matches most of them with incomplete or even wrong city, region, country information (e.g. way 62120822: Calle Calvario, CÁCERES (should be BADAJOZ), ESP). Cáceres is relation 349018 and Badajoz 348994. Locator r1925+spain.osm.pbf 28/4 -> same result. Note mkgmap didn't complain about mp 346527. The boundary tiles are extracted daily from the same pbf file than map. My locator related styles: mkgmap:country!=*& addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=*& is_in:country=* { set mkgmap:country='${is_in:country}' } mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=*& is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=*& mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=*& mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=*& mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=*& openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=*& is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=*& addr:city=* { set mkgmap:city='${addr:city}' } 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: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}' }
My commands: osmosis --read-pbf file="spain.osm.pbf" --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --write-xml file="spain-boundaries.osm" time /usr/lib/jvm/java-6-sun/bin/java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=spain-boundaries.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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
El 28/04/11 21:49, WanMil escribió:
Carlos,
thanks for your reports. I cannot check your examples in detail now but I can give you some general hints.
The current locator branch relies on complete boundaries. The word complete is important. The boundary precompilation algorithm does not automatically close multipolygons which are open and which has a loose endpoints out of the tile borders. This is necessary because one major reason for using precompiled data is that I want to get rid of wrong autoclosed boundaries. (Please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010797.html where I tried to explain the problem more in detail). I know the importance of complete boundaries. That's the reason I'm trying to fix all incomplete ones detected by mkgmap. If you use a dump of spain only you might loose some of the boundaries that are located on the border. I would recommend to download a larger dump and cut out a larger area than spain for boundary precompilation (e.g. spain + 10km around). I modified the cut polygon used by Geofabrik for the Spain dump a few weeks ago, so that it fits exactly Spanish border+ a few meters, so no boundary near the border should be cut. In fact, I have not faced any one detected by mp processing. Only a couple of boundaries are cut due to some changes I did yesterday in a portion of the border. Of course the changes are not tested very well and there are tons of bugs in it. I'll have to implement some checks to see if the precompilation really works well.
WanMil
These are the results of my first (limited) tests: The list of places under State/Province field in MapSource "Search places" includes a lot more wrong places than without the boundary precompilation (locator r1922). For example I get State/Province "La Zubia" (from relation 347255) and place "Cumbres Verdes (node 1107558640), LA ZUBIA, ESP" under it. In the last days I've been correcting incomplete boundary polygons from mkgmap log. Searching for a random street (Calle Calvario) that exists within one of these multipolygons I fixed yesterday (relation 346527) I get the following: Trunk+spain.osm.pbf 28/4-> 46 "Calle Calvario" matches with complete city, region, country information (e.g. way 62120822: Calle Calvario, Alburquerque, EXTREMADURA, ESP) Locator r1925+spain.osm.pbf 27/4 -> 39 matches most of them with incomplete or even wrong city, region, country information (e.g. way 62120822: Calle Calvario, CÁCERES (should be BADAJOZ), ESP). Cáceres is relation 349018 and Badajoz 348994. Locator r1925+spain.osm.pbf 28/4 -> same result. Note mkgmap didn't complain about mp 346527. The boundary tiles are extracted daily from the same pbf file than map. My locator related styles: mkgmap:country!=*& addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=*& is_in:country=* { set mkgmap:country='${is_in:country}' } mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=*& is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=*& mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=*& mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=*& mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=*& openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=*& is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=*& addr:city=* { set mkgmap:city='${addr:city}' } 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: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}' }
My commands: osmosis --read-pbf file="spain.osm.pbf" --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --write-xml file="spain-boundaries.osm" time /usr/lib/jvm/java-6-sun/bin/java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=spain-boundaries.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 _______________________________________________ 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
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
It seems r1929 did the trick. Now I get 44 matches for "Calle Calvario" (vs 46 with trunk), all of them but two with complete city, region, country information. Also most of the States/Provinces are now correct. El 28/04/11 23:23, Carlos Dávila escribió:
El 28/04/11 21:49, WanMil escribió:
Carlos,
thanks for your reports. I cannot check your examples in detail now but I can give you some general hints.
The current locator branch relies on complete boundaries. The word complete is important. The boundary precompilation algorithm does not automatically close multipolygons which are open and which has a loose endpoints out of the tile borders. This is necessary because one major reason for using precompiled data is that I want to get rid of wrong autoclosed boundaries. (Please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010797.html where I tried to explain the problem more in detail). I know the importance of complete boundaries. That's the reason I'm trying to fix all incomplete ones detected by mkgmap. If you use a dump of spain only you might loose some of the boundaries that are located on the border. I would recommend to download a larger dump and cut out a larger area than spain for boundary precompilation (e.g. spain + 10km around). I modified the cut polygon used by Geofabrik for the Spain dump a few weeks ago, so that it fits exactly Spanish border+ a few meters, so no boundary near the border should be cut. In fact, I have not faced any one detected by mp processing. Only a couple of boundaries are cut due to some changes I did yesterday in a portion of the border. Of course the changes are not tested very well and there are tons of bugs in it. I'll have to implement some checks to see if the precompilation really works well.
WanMil
These are the results of my first (limited) tests: The list of places under State/Province field in MapSource "Search places" includes a lot more wrong places than without the boundary precompilation (locator r1922). For example I get State/Province "La Zubia" (from relation 347255) and place "Cumbres Verdes (node 1107558640), LA ZUBIA, ESP" under it. In the last days I've been correcting incomplete boundary polygons from mkgmap log. Searching for a random street (Calle Calvario) that exists within one of these multipolygons I fixed yesterday (relation 346527) I get the following: Trunk+spain.osm.pbf 28/4-> 46 "Calle Calvario" matches with complete city, region, country information (e.g. way 62120822: Calle Calvario, Alburquerque, EXTREMADURA, ESP) Locator r1925+spain.osm.pbf 27/4 -> 39 matches most of them with incomplete or even wrong city, region, country information (e.g. way 62120822: Calle Calvario, CÁCERES (should be BADAJOZ), ESP). Cáceres is relation 349018 and Badajoz 348994. Locator r1925+spain.osm.pbf 28/4 -> same result. Note mkgmap didn't complain about mp 346527. The boundary tiles are extracted daily from the same pbf file than map. My locator related styles: mkgmap:country!=*& addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=*& is_in:country=* { set mkgmap:country='${is_in:country}' } mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=*& is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=*& mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=*& mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=*& mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=*& openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=*& is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=*& addr:city=* { set mkgmap:city='${addr:city}' } 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: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}' }
My commands: osmosis --read-pbf file="spain.osm.pbf" --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --write-xml file="spain-boundaries.osm" time /usr/lib/jvm/java-6-sun/bin/java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=spain-boundaries.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 _______________________________________________ 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
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
Great! That was a silly bug... I think I found another big issue that affects quite a lot of boundaries. My osmosis command line was not complete. Ways without boundary=administrative were not contained in the output file. I think for this the --used-way parameter must be added. It is new in osmosis 0.39. I started osmosis with the europe dump from today. Hopefully that works and then I will upload the precompiled tiles. Details where you can download them will be posted afterwards. WanMil
It seems r1929 did the trick. Now I get 44 matches for "Calle Calvario" (vs 46 with trunk), all of them but two with complete city, region, country information. Also most of the States/Provinces are now correct.
El 28/04/11 23:23, Carlos Dávila escribió:
El 28/04/11 21:49, WanMil escribió:
Carlos,
thanks for your reports. I cannot check your examples in detail now but I can give you some general hints.
The current locator branch relies on complete boundaries. The word complete is important. The boundary precompilation algorithm does not automatically close multipolygons which are open and which has a loose endpoints out of the tile borders. This is necessary because one major reason for using precompiled data is that I want to get rid of wrong autoclosed boundaries. (Please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010797.html where I tried to explain the problem more in detail). I know the importance of complete boundaries. That's the reason I'm trying to fix all incomplete ones detected by mkgmap. If you use a dump of spain only you might loose some of the boundaries that are located on the border. I would recommend to download a larger dump and cut out a larger area than spain for boundary precompilation (e.g. spain + 10km around). I modified the cut polygon used by Geofabrik for the Spain dump a few weeks ago, so that it fits exactly Spanish border+ a few meters, so no boundary near the border should be cut. In fact, I have not faced any one detected by mp processing. Only a couple of boundaries are cut due to some changes I did yesterday in a portion of the border. Of course the changes are not tested very well and there are tons of bugs in it. I'll have to implement some checks to see if the precompilation really works well.
WanMil
These are the results of my first (limited) tests: The list of places under State/Province field in MapSource "Search places" includes a lot more wrong places than without the boundary precompilation (locator r1922). For example I get State/Province "La Zubia" (from relation 347255) and place "Cumbres Verdes (node 1107558640), LA ZUBIA, ESP" under it. In the last days I've been correcting incomplete boundary polygons from mkgmap log. Searching for a random street (Calle Calvario) that exists within one of these multipolygons I fixed yesterday (relation 346527) I get the following: Trunk+spain.osm.pbf 28/4-> 46 "Calle Calvario" matches with complete city, region, country information (e.g. way 62120822: Calle Calvario, Alburquerque, EXTREMADURA, ESP) Locator r1925+spain.osm.pbf 27/4 -> 39 matches most of them with incomplete or even wrong city, region, country information (e.g. way 62120822: Calle Calvario, CÁCERES (should be BADAJOZ), ESP). Cáceres is relation 349018 and Badajoz 348994. Locator r1925+spain.osm.pbf 28/4 -> same result. Note mkgmap didn't complain about mp 346527. The boundary tiles are extracted daily from the same pbf file than map. My locator related styles: mkgmap:country!=*& addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=*& is_in:country=* { set mkgmap:country='${is_in:country}' } mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=*& is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=*& mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=*& mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=*& mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=*& openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=*& is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=*& addr:city=* { set mkgmap:city='${addr:city}' } 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: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}' }
My commands: osmosis --read-pbf file="spain.osm.pbf" --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --write-xml file="spain-boundaries.osm" time /usr/lib/jvm/java-6-sun/bin/java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=spain-boundaries.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 _______________________________________________ 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
The European boundaries compiled by WanMil are available for download: http://www.navmaps.eu/wanmil/europe_bounds_20110429.zip Johan On Fri, 29 Apr 2011 22:49:54 +0200, WanMil <wmgcnfg@web.de> wrote:
Great! That was a silly bug...
I think I found another big issue that affects quite a lot of boundaries. My osmosis command line was not complete. Ways without boundary=administrative were not contained in the output file. I think for this the --used-way parameter must be added. It is new in osmosis 0.39.
I started osmosis with the europe dump from today. Hopefully that works and then I will upload the precompiled tiles. Details where you can download them will be posted afterwards.
WanMil
It seems r1929 did the trick. Now I get 44 matches for "Calle Calvario" (vs 46 with trunk), all of them but two with complete city, region, country information. Also most of the States/Provinces are now correct.
El 28/04/11 23:23, Carlos Dávila escribió:
El 28/04/11 21:49, WanMil escribió:
Carlos,
thanks for your reports. I cannot check your examples in detail now but I can give you some general hints.
The current locator branch relies on complete boundaries. The word complete is important. The boundary precompilation algorithm does not automatically close multipolygons which are open and which has a loose endpoints out of the tile borders. This is necessary because one major reason for using precompiled data is that I want to get rid of wrong autoclosed boundaries. (Please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010797.html where I tried to explain the problem more in detail). I know the importance of complete boundaries. That's the reason I'm trying to fix all incomplete ones detected by mkgmap. If you use a dump of spain only you might loose some of the boundaries that are located on the border. I would recommend to download a larger dump and cut out a larger area than spain for boundary precompilation (e.g. spain + 10km around). I modified the cut polygon used by Geofabrik for the Spain dump a few weeks ago, so that it fits exactly Spanish border+ a few meters, so no boundary near the border should be cut. In fact, I have not faced any one detected by mp processing. Only a couple of boundaries are cut due to some changes I did yesterday in a portion of the border. Of course the changes are not tested very well and there are tons of bugs in it. I'll have to implement some checks to see if the precompilation really works well.
WanMil
These are the results of my first (limited) tests: The list of places under State/Province field in MapSource "Search places" includes a lot more wrong places than without the boundary precompilation (locator r1922). For example I get State/Province "La Zubia" (from relation 347255) and place "Cumbres Verdes (node 1107558640), LA ZUBIA, ESP" under it. In the last days I've been correcting incomplete boundary polygons from mkgmap log. Searching for a random street (Calle Calvario) that exists within one of these multipolygons I fixed yesterday (relation 346527) I get the following: Trunk+spain.osm.pbf 28/4-> 46 "Calle Calvario" matches with complete city, region, country information (e.g. way 62120822: Calle Calvario, Alburquerque, EXTREMADURA, ESP) Locator r1925+spain.osm.pbf 27/4 -> 39 matches most of them with incomplete or even wrong city, region, country information (e.g. way 62120822: Calle Calvario, CÁCERES (should be BADAJOZ), ESP). Cáceres is relation 349018 and Badajoz 348994. Locator r1925+spain.osm.pbf 28/4 -> same result. Note mkgmap didn't complain about mp 346527. The boundary tiles are extracted daily from the same pbf file than map. My locator related styles: mkgmap:country!=*& addr:country=* { set mkgmap:country='${addr:country}' } mkgmap:country!=*& is_in:country=* { set mkgmap:country='${is_in:country}' } mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=*& is_in:province=* { set mkgmap:region='${is_in:province}' } mkgmap:region!=*& mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' } mkgmap:region!=*& mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=*& mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=*& openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=*& is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=*& addr:city=* { set mkgmap:city='${addr:city}' } 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: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}' }
My commands: osmosis --read-pbf file="spain.osm.pbf" --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-node --write-xml file="spain-boundaries.osm" time /usr/lib/jvm/java-6-sun/bin/java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=spain-boundaries.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 _______________________________________________ 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
On Apr 30, 2011, at 8:51, navmaps wrote:
The European boundaries compiled by WanMil are available for download: http://www.navmaps.eu/wanmil/europe_bounds_20110429.zip
Thanks for uploading the file. Regarding the boundary function, when I compile, I notice a few errors in the log file for bounds_2050000_100000.bnd: 2011/04/30 10:29:20 SEVERE (BoundaryUtil): 94000001.osm.gz: Cannot load boundary file bounds/bounds_2050000_100000.bnd: java.io.UTFDataFormatException: malformed input around byte 250 Is there a bad character compiled into this file? It seems to function correctly otherwise. Cheers.
On Apr 30, 2011, at 8:51, navmaps wrote:
The European boundaries compiled by WanMil are available for download: http://www.navmaps.eu/wanmil/europe_bounds_20110429.zip
Thanks for uploading the file.
Regarding the boundary function, when I compile, I notice a few errors in the log file for bounds_2050000_100000.bnd:
2011/04/30 10:29:20 SEVERE (BoundaryUtil): 94000001.osm.gz: Cannot load boundary file bounds/bounds_2050000_100000.bnd: java.io.UTFDataFormatException: malformed input around byte 250
Is there a bad character compiled into this file?
It seems to function correctly otherwise.
Cheers.
I've seen such an error too but I couldn't find out what's the real problem. When I run the BoundaryFile2Gpx on this file everythings ok. I have two ideas: 1. Maybe the boundary utils are not thread safe. Do you use more than one thread? 2. The file format for each boundary starts with the boundary rect and then the size that must be skipped to reach the next boundary. This is used to load only those boundaries which intersects the tile. Maybe there is a problem in this size information. I will check that. WanMil
Am 30.04.2011 13:58, schrieb Clinton Gladstone:
On Apr 30, 2011, at 13:43, WanMil wrote:
1. Maybe the boundary utils are not thread safe. Do you use more than one thread?
I still get the error with only one thread.
By the way, I'm on Mac OS with Java version "1.6.0_24" (64 bit), if that's any help.
Cheers.
Could you please try to run the BoundaryFile2Gpx converter for this boundary file? java -cp mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryFile2Gpx bounds/bounds_2050000_100000.bnd Does it throw the same error? I am not sure if I there is a problem with the big- and little-endian order on Mac versus PC? WanMil
On Apr 30, 2011, at 15:13, WanMil wrote:
Could you please try to run the BoundaryFile2Gpx converter for this boundary file?
Does it throw the same error? I am not sure if I there is a problem with the big- and little-endian order on Mac versus PC?
The converter does not produce an error. I get the following output: true false bounds_2050000_100000.bnd Start converting bounds_2050000_100000.bnd 318 boundaries loaded Finished bounds_2050000_100000.bnd (Since I am using an Intel Mac there should not be an endian problem.) I'll see if I can narrow down the problem on my side. Cheers.
I have tried locator v1928 with the uploaded europe-boundaries but still no success. In Mapsource about 45/80 of the random streets that I tested had no placename. In all those cases mkgmap-locator-r1915.jar could find a matching placename. If I look to those places that could be matched with a placename, and I enter the placename on the GPS, the streets show up in a list but if I choose that street no location can be found. I can only find that location by skipping the placename and enter the streetname directly. With the other 50% (streets with no location in Mapsource) they are not searchable at all on the GPS. With r1915 most of the streets were found, even on the GPS. I also examined the logfile. This street couldn't be found with a matching place (Tilburg) http://www.openstreetmap.org/browse/way/77208790 (locator 1928 can't find not just one street in Tilburg, a big city, locator 1915 finds many streets there) In the logfile I found these messages: Added tag mkgmap:admin_level2 = NLD to [name=Cyprespad,highway=pedestrian,mkgmap:admin_level2=NLD Added tag mkgmap:admin_level4 = Noord-Brabant to [name=Cyprespad,highway=pedestrian,mkgmap:admin_level2=NLD,mkgmap:admin_level4=Noord-Brabant Nothing more, no admin_level 8 and 10 are matched. One example of a street that could be matched in Mapsource with a placename: Added tag mkgmap:admin_level8 = Gilze en Rijen to [name=Gerardus Majellastraat,mkgmap:admin_level8=Gilze en Rijen,highway=unclassified Added tag mkgmap:admin_level10 = Hulten to [name=Gerardus Majellastraat,mkgmap:admin_level8=Gilze en Rijen,highway=unclassified,mkgmap:admin_level10=Hulten Added tag mkgmap:admin_level2 = NLD to [name=Gerardus Majellastraat,highway=unclassified,mkgmap:admin_level2=NLD Added tag mkgmap:admin_level4 = Noord-Brabant to [name=Gerardus Majellastraat,highway=unclassified,mkgmap:admin_level2=NLD,mkgmap:admin_level4=Noord-Brabant If I enter "Hulten" on the GPS, the streetname "Gerardus Majellastraat" shows up in the list of streetnames, but if I click on it, no location can be found. If I skip the placename, and enter directly the name Gerardus Majellastraat, the location can be found.
Minko, please try the latest r1930. Carlos reported that r1929 did the trick for him (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011245.html). WanMil
I have tried locator v1928 with the uploaded europe-boundaries but still no success. In Mapsource about 45/80 of the random streets that I tested had no placename. In all those cases mkgmap-locator-r1915.jar could find a matching placename. If I look to those places that could be matched with a placename, and I enter the placename on the GPS, the streets show up in a list but if I choose that street no location can be found. I can only find that location by skipping the placename and enter the streetname directly. With the other 50% (streets with no location in Mapsource) they are not searchable at all on the GPS. With r1915 most of the streets were found, even on the GPS.
I also examined the logfile. This street couldn't be found with a matching place (Tilburg) http://www.openstreetmap.org/browse/way/77208790 (locator 1928 can't find not just one street in Tilburg, a big city, locator 1915 finds many streets there)
In the logfile I found these messages:
Added tag mkgmap:admin_level2 = NLD to [name=Cyprespad,highway=pedestrian,mkgmap:admin_level2=NLD Added tag mkgmap:admin_level4 = Noord-Brabant to [name=Cyprespad,highway=pedestrian,mkgmap:admin_level2=NLD,mkgmap:admin_level4=Noord-Brabant
Nothing more, no admin_level 8 and 10 are matched.
One example of a street that could be matched in Mapsource with a placename:
Added tag mkgmap:admin_level8 = Gilze en Rijen to [name=Gerardus Majellastraat,mkgmap:admin_level8=Gilze en Rijen,highway=unclassified Added tag mkgmap:admin_level10 = Hulten to [name=Gerardus Majellastraat,mkgmap:admin_level8=Gilze en Rijen,highway=unclassified,mkgmap:admin_level10=Hulten Added tag mkgmap:admin_level2 = NLD to [name=Gerardus Majellastraat,highway=unclassified,mkgmap:admin_level2=NLD Added tag mkgmap:admin_level4 = Noord-Brabant to [name=Gerardus Majellastraat,highway=unclassified,mkgmap:admin_level2=NLD,mkgmap:admin_level4=Noord-Brabant
If I enter "Hulten" on the GPS, the streetname "Gerardus Majellastraat" shows up in the list of streetnames, but if I click on it, no location can be found. If I skip the placename, and enter directly the name Gerardus Majellastraat, the location can be found.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I'm sorry, it didnt work either. In short, a) entering a placename NEVER gives a matching location (tested on a nüvi) b) skipping the placename, roughly 50% of the streetnames have matching places and a location can be found. tested this on two tiles: 10010037: 2394112,225280 to 2410496,241664 # : 51.372070,4.833984 to 51.723633,5.185547 10010049: 2390016,204800 to 2410496,225280 # : 51.284180,4.394531 to 51.723633,4.833984 Another tile had better results (all streets seemed to have corresponding places) but on the GPS searching via placenames didnt work either. mkgmap settings: family-id: 30010 product-id: 1 draw-priority: 20 description: ofm_test country-name: BNL country-abbr: #style-file: Styles (custom on or off didnt seem to have any effect) generate-sea: extend-sea-sectors,close-gaps=6000,floodblocker,land-tag=natural=background #createboundsfile: c:\downloads\europe-boundaries.osm boundsdirectory: c:\downloads\bounds latin1 code-page: 1252 location-autofill: 0 show-profiles=1 ignore-maxspeeds remove-short-arcs merge-lines add-pois-to-areas min-size-polygon: 4 preserve-element-order keep-going net route index nsis
I narrowed down one problem, that when the locator did find a match between a street and a place the GPS couldn't find a location. This only works if I skip the mkgmap:country and region lines in the style file, the GPS now can locate the streets that are found under the placenames. mkgmap:city!=* & openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' } mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } This leaves some issues and adds some more: -Locator r1930 still cannot locate a lot of streets (locator r1915 could maybe find 90% locator 1930 maybe 50%). -Countries and regions are not set One other thing I noticed, that under the place name Breda (relation=297129) only the streets could be found that were lying in one bounds section: bounds_2400000_200000.bnd (Streets in breda not found, but relation 297129 is found in this file) bounds_2350000_200000.bnd (streets found) http://www.openstreetmap.org/?lat=51.4901&lon=4.7498&zoom=14&layers=M&relati... ----- Oorspronkelijk bericht ----- I wrote: I'm sorry, it didnt work either. In short, a) entering a placename NEVER gives a matching location (tested on a nüvi) b) skipping the placename, roughly 50% of the streetnames have matching places and a location can be found. tested this on two tiles: 10010037: 2394112,225280 to 2410496,241664 # : 51.372070,4.833984 to 51.723633,5.185547 10010049: 2390016,204800 to 2410496,225280 # : 51.284180,4.394531 to 51.723633,4.833984 Another tile had better results (all streets seemed to have corresponding places) but on the GPS searching via placenames didnt work either. mkgmap settings: family-id: 30010 product-id: 1 draw-priority: 20 description: ofm_test country-name: BNL country-abbr: #style-file: Styles (custom on or off didnt seem to have any effect) generate-sea: extend-sea-sectors,close-gaps=6000,floodblocker,land-tag=natural=background #createboundsfile: c:\downloads\europe-boundaries.osm boundsdirectory: c:\downloads\bounds latin1 code-page: 1252 location-autofill: 0 show-profiles=1 ignore-maxspeeds remove-short-arcs merge-lines add-pois-to-areas min-size-polygon: 4 preserve-element-order keep-going net route index nsis _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
El 01/05/11 10:43, Minko escribió:
One other thing I noticed, that under the place name Breda (relation=297129) only the streets could be found that were lying in one bounds section: bounds_2400000_200000.bnd (Streets in breda not found, but relation 297129 is found in this file) Have you converted to gpx and checked if relation 297129 is correct in it? If not, try to get the right boundaries with osmosis. See at [1] what worked for me. [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011264.html bounds_2350000_200000.bnd (streets found)
http://www.openstreetmap.org/?lat=51.4901&lon=4.7498&zoom=14&layers=M&relati...
----- Oorspronkelijk bericht ----- I wrote:
I'm sorry, it didnt work either.
In short, a) entering a placename NEVER gives a matching location (tested on a nüvi) b) skipping the placename, roughly 50% of the streetnames have matching places and a location can be found.
tested this on two tiles:
10010037: 2394112,225280 to 2410496,241664 # : 51.372070,4.833984 to 51.723633,5.185547
10010049: 2390016,204800 to 2410496,225280 # : 51.284180,4.394531 to 51.723633,4.833984
Another tile had better results (all streets seemed to have corresponding places) but on the GPS searching via placenames didnt work either.
mkgmap settings:
family-id: 30010 product-id: 1 draw-priority: 20 description: ofm_test country-name: BNL country-abbr: #style-file: Styles (custom on or off didnt seem to have any effect) generate-sea: extend-sea-sectors,close-gaps=6000,floodblocker,land-tag=natural=background #createboundsfile: c:\downloads\europe-boundaries.osm boundsdirectory: c:\downloads\bounds latin1 code-page: 1252 location-autofill: 0 show-profiles=1 ignore-maxspeeds remove-short-arcs merge-lines add-pois-to-areas min-size-polygon: 4 preserve-element-order keep-going net route index nsis _______________________________________________ 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
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
Yes, there is a file 8_r297129_o_0.gpx, it follows the boundaries, but how can I see if it's correct?
Carlos, Relation 297129 matches with the gpx file for the part that falls within the bounds_2400000_200000.bnd file. Relation 297049 lies totally within bounds_2400000_200000.bnd file and also seem to match with the gpx file 10_r297049_o_0.gpx So I think there must be something else wrong. Have you tested it also on a GPS?
El 01/05/11 16:05, Minko escribió:
Carlos, Relation 297129 matches with the gpx file for the part that falls within the bounds_2400000_200000.bnd file. Relation 297049 lies totally within bounds_2400000_200000.bnd file and also seem to match with the gpx file 10_r297049_o_0.gpx So I think there must be something else wrong. Have you tested it also on a GPS? I have just tested on a nuvi 300 and a legend hcx and it works fine.
participants (12)
-
Carlos Dávila -
Charlie Ferrero -
Clinton Gladstone -
Felix Hartmann -
Henning Scholland -
Lambertus -
Markus_g -
Martin -
Minko -
navmaps -
Steve Ratcliffe -
WanMil