[mkgmap-dev] [PATCH v6] Automatic location completion

Thu Mar 10 02:53:11 GMT 2011

Thanks for jar file.  Now to report my test results:
I uploaded the map via Garmin MapInstall search for "Address" and
"Intersections".  I get a "No Data Available"

Using: mkgmap-locator-r1892.jar

Args.list:
ode-page=1252
tdbfile
latin1
country-abbr=PHL
country-name=PHILIPPINES
remove-short-arcs=5
route
add-pois-to-areas
family-id=639
family-name=OSM_PHIL
overview-mapname=40000001
series-name=OSM_PHIL
description=OSM_PHIL
style-file=/home/maning/Downloads/osm/routable_garmin/git/osmphgps/styles/default
generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000
index
make-poi-index
adjust-turn-headings
drive-on-right
report-dead-ends
ignore-maxspeeds
link-pois-to-ways
location-autofill=0

Some error reports:
SEVERE (LocationHook): philippines.osm: Element lists created after 230 ms
SEVERE (LocationHook): philippines.osm: Quadtree created after 23798 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=1
processed after 23815 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=2
processed after 23864 ms
SEVERE (LocationHook): philippines.osm: Start assigning  admin_level=2
after 23962 ms
SEVERE (LocationHook): philippines.osm: Special admin_level=2 handling
processed after 24627 ms
SEVERE (LocationHook): philippines.osm: Cannot process location
element because it contains no name tag: 4611686018427393428
[boundary=administrative,admin_level=3,mkgmap:stylefilter=polygon,mkgmap:admin_level2=PHL]
SEVERE (LocationHook): philippines.osm: Location admin_level=3
processed after 40069 ms
SEVERE (LocationHook): philippines.osm: Cannot process location
element because it contains no name tag: 61462633
[boundary=administrative,admin_level=4,mkgmap:admin_level2=PHL]
SEVERE (LocationHook): philippines.osm: Cannot process location
element because it contains no name tag: 4611686018427387951
[boundary=administrative,admin_level=4,mkgmap:stylefilter=polygon,mkgmap:admin_level2=PHL]
SEVERE (LocationHook): philippines.osm: Cannot process location
element because it contains no name tag: 27751466
[boundary=administrative,admin_level=4,mkgmap:admin_level2=PHL]
SEVERE (LocationHook): philippines.osm: Location admin_level=4
processed after 40335 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=5
processed after 40336 ms
SEVERE (LocationHook): philippines.osm: Cannot process location
element because it contains no name tag: 28045303
[mkgmap:admin_level6=Makati,boundary=administrative,admin_level=6,mkgmap:admin_level2=PHL,mkgmap:admin_level3=Metro
Manila]
SEVERE (LocationHook): philippines.osm: Location admin_level=6
processed after 42682 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=7
processed after 42683 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=8
processed after 42823 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=9
processed after 42836 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=10
processed after 44427 ms
SEVERE (LocationHook): philippines.osm: Location admin_level=11
processed after 44427 ms
SEVERE (LocationHook): philippines.osm: Location postal_code processed
after 44427 ms
SEVERE (LocationHook): philippines.osm: Location hook finished in 44427 ms

Next I tried using the default style and now I can search for streets
via "Address".  There must be something wrong with my own style
Moving on, for areas with proper relation/multipolygon I get good
results for streets within villages (admin_level=10
http://www.openstreetmap.org/browse/relation/371327) but I can't get
streets within tows/cities (admin_level=6
http://www.openstreetmap.org/browse/relation/146949)

One question, does your code split the road when it crosses another admin_level?

2011/3/10 Carlos Dávila <cdavilam at orangecorreo.es>:
> El 08/03/11 23:07, WanMil escribió:
>
> Next round of the location improvements:
> * The algorithm that searched which elements were contained within a
> boundary was (is) wrong. I updated some parameters in the Quadtree so I the
> probability is very much lower that an element is not assigned correctly.
>
> In case they can help you improve the algorithm, here you have two examples
> of nodes wrongly assigned (according to my styles below): nodes 945168390
> and 943005606, that are within boundary relation 348994 (admin_level=6) are
> assigned region=Extremadura (boundary relation 349050, admin_level=4). I can
> provide more examples if necessary.
> Extract of the styles:
> 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}' }
>
> * The mkgmap:country, addr:country and is_in:country tag is now always
> assigned with the three letter country code. This makes it possible to
> define country specific rules in the style files.
>
> With no changed on your mkgmap:country rules in styles I have (among others)
> Esp and España (ESP) in the list of countries. If I select Esp, a full list
> of places is found, but if I select España (ESP), nothing in found.
>
> A note ot Carlos:
> With this patch you can add debug rules to the style file. So if you don't
> understand why a specific region/country is used add the following line to
> your style files:
> mkgmap:region=* { echo "R=${mkgmap:region} 3=${mkgmap:admin_level3}
> 4=3=${mkgmap:admin_level4} 5=${mkgmap:admin_level5} 6=${mkgmap:admin_level6}
> is_in=${is_in:region}" }
>
> How can I send the echo output to a file? I tried java -jar mkgmap.jar
> options input_files > textfile with no success
>
> I think your rules are ok.
>
> By the way: Should I create a branch for my changes? Maybe this makes it
> easier for more people to test and to play with?
>
> WanMil
>
> El 06/03/11 19:40, WanMil escribió:
>
> I implemented Minkos idea using the style file to set the city,
> region, zip and country names.
>
> How does it work?
> The new AddressHook adds special tags to each element that is inside a
> known boundary:
> mkgmap:admin_level2
> mkgmap:admin_level3
> mkgmap:admin_level4
> ..
> mkgmap:admin_level11
>
> If an admin_level is not known the relevant tag is not set. The same
> for the zip tag mkgmap:postalcode.
>
> The style file contains a new rule block (in each file):
> 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:county=*
>    { set mkgmap:region='${is_in:county}' }
> mkgmap:region!=* & mkgmap:admin_level6=*
>    { set mkgmap:region='${mkgmap:admin_level6}' }
> ...
>
> mkgmap:city!=* & openGeoDB:name=*
>    { set mkgmap:city='${openGeoDB:name}' }
> 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!=* & mkgmap:postcode=*
>    { set mkgmap:postal_code='${mkgmap:postalcode}' }
>
> These rules set the mkgmap tags:
> mkgmap:country
> mkgmap:region
> mkgmap:city
> mkgmap:postal_code
>
> Only these tags are used to set the country, the region, the city and
> the zip code. No more rules are applied automatically (there are still
> some in the Locator class but they will be removed).
>
> This enables you to configure which admin_level information you want
> to use for the city name, the region names etc. Also country specific
> rules are possible (e.g. add a mkgmap:country=NLD rule).
>
> Todo: The country normalization must be performed by the AddressHook
> so that one can be sure that the Netherlands are always tagged with
> mkgmap:country=NLD (or mkgmap:country=Nederland?)
>
> The rules are not perfect up to now but please feel free to post some
> good rules for your country.
>
> I have changed my styles as follows,
>
> mkgmap:region!=* & is_in:region=* { set mkgmap:region='${is_in:region}' }
> mkgmap:region!=* & mkgmap:admin_level4=* { set
> mkgmap:region='${mkgmap:admin_level4}' }
> 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_level3=* { set
> mkgmap:region='${mkgmap:admin_level3}' }
>
> to adapt them to what I think is best for Spain, but, if I understood
> well, something is not working as expected: places tagged as villages
> that have no is_in:region information and are within admin_level=4 and
> admin_level=6 polygons take the region from the a_l=6 polygon, instead
> of a_l=4 as it should be from the style above.
>
> WanMil
>
>
> Attached is the next step for the automatic location completion:
> * Some speed improvements (it's still slow but not as slow as before ;-)
> * boundary=postal_code is now supported.
> * The Locator does no longer overwrite already set attributes. This
> seems to be a better solution. I think the Locator must be rewritten
> completely. Up to now I have commented some lines only without deep
> understanding what it is really doing.
>
> Some things that don't work:
> * Lot's of POIs are assigned with the default country although the
> MapElements are assigned with the correct country. Example:
> - Spain splitted with --overlap=3000 (more overlap is better for my
> patch)
> - Cafe Antxi (http://www.openstreetmap.org/browse/node/629554219) is
> correctly assigned with country=ESP but in the POI search it is
> displayed with the default country.
> I have no idea why.
>
> * Zips are only applied to POIs. Streets seems to be not yet supported
> by the MDR creation. (=> Steve?)
>
> Things to do:
> * Speed improvement (At the moment the location search takes as much
> time as the rest of the map creation)
> * A better mapping of city, region to the admin-levels
> * Make use more OSM information (like residential areas, place=city POIs
> in residential areas etc.)
> * Clean up of the Locator class
>
> WanMil
>
>
> I have improved calculation of the country information. In case no
> country information is available the most used country in a tile is
> used
> for all elements without country tag.
>
> The patch now patches the trunk and no longer the index branch.
>
> I have observed that lots of POIs are assigned the default country
> although I they are assigned a different country. I have no clue where
> this happens.
> Maybe an index related problem? I was hoping that Steves commit today
> would fix that problem but it didn't.
>
> WanMil
>
> I have done some development and want you to share my current
> findings.
>
> 1. The MapElement copy constructor seems to have a bug. The attributes
> map which contains the city, region and country information is not
> copied. From my point of view this is an important thing that
> should be
> fixed in the trunk also.
>
> 2. In the patch the Locator is disabled as much as it was possible for
> me up to now.
>
> 3. I am using now separate tags (mkgmap:city, mkgmap:region etc.).
>
> I recommend to run this patch with location-autofill=-1 or 0 to see
> how
> the patch works and not how the old Locator works.
>
> WanMil
>
>
> After the index branch has been developed so far that we can use the
> results in MapSource (thanks to Steve!!) there is a big need for a
> mechanism to fill missing location information.
>
> There has been a lot of discussion about that. It stopped because it
> was
> quite theoretical (from my point of view). Therefore I have
> started to
> implement a prototype osm hook that tries to complete the missing
> location information. I think the is_in tag is quite problematic
> therefore I decided to use the addr tags.
>
> Attached is a *very* early implementation that makes use of the
> boundary
> polygons. It checks all nodes and ways/polygons within all boundary
> polygons and fills the missing addr tags.
>
> I think this is a better foundation for the discussion how we want to
> fill the missing location information.
>
> Before flaming me about terrible code please be aware that:
> * the patch is not optimized
> * it's version 1, so far away from handling all situations /
> countries
> * it's a very early prototype
>
> I would be happy if you try it and make some proposals how it
> could be
> improved.
>
> Some improvements I already know and thinking about:
> * The new hook should run after the multipolygon finishing and not
> before
> * The is_in tag should be handled
> * boundary information propagation => First go through all boundaries
> and add the information from higher levels to lower ones, i.e. add
> addr:district to all city boundaries within that district
> * Use landuse=residential information in combination with the place
> nodes
> * In case a boundary level is missing (which mostly will be the case
> for
> countries admin_level=2), select the addr information from all nodes
> and
> ways within a boundary by using the most used addr-tag value. (in
> germany the addr:country=DE should be the most used)
>
>
> Have fun!
> WanMil
>
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at 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.
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
cheers,
maning
------------------------------------------------------
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
------------------------------------------------------