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.