
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it. So please post your country specific rules as an answer in this thread. WanMil

Netherlands: mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } For Belgium I'm not sure, seems a big mess there ;-) Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134 Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }

Am 04.05.2011 19:38, schrieb Minko:
Netherlands:
mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
Thanks! They are committed in r1936 WanMil

In Germany we have the same mess... Actually I'm using this rules: 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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany. Thanks and regards Martin Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Am 04.05.2011 20:32, schrieb Martin:
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
I would use: mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:country="DEU" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="DEU" & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } Henning

I think only the city rules need to be tweaked in Germany: # Germany = DEU cities mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6. Please try it and give a feedback if that's ok. The upper rules are committed in r1937. Later on I will try your region settings. WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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

in addition to Minko: according to http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries Belgium provinces should all be in admin_level 6 For Luxembourg: the cities are all in admin_level 8, the provinces (I think the Luxembourg name 'district' comes closest) are in admin_level 4 Cheers Johan On Wed, 04 May 2011 21:03:00 +0200, WanMil <wmgcnfg@web.de> wrote:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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 Wanmil, some problems using the country specific cities, maybe the locator config has to be slightly changed: (1) Boundary name OSM (2) Locator name (3) Result (1) Deutschland (2) Deutschland (3) positive, can be found in Garmin (1) Nederland (2) Nederland (3) positive, can be found in Garmin (1) Groussherzogtum Lëtzebuerg (2) Luxembourg (3) negative, can't be found in Garmin (1) België - Belgique - Belgien (2) Belgique (3) negative, can't be found in Garmin Cheers, Johan On Wed, 04 May 2011 22:23:54 +0200, navmaps <navmaps@navmaps.eu> wrote:
in addition to Minko: according to http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries Belgium provinces should all be in admin_level 6
For Luxembourg: the cities are all in admin_level 8, the provinces (I think the Luxembourg name 'district' comes closest) are in admin_level 4
Cheers Johan
On Wed, 04 May 2011 21:03:00 +0200, WanMil <wmgcnfg@web.de> wrote:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Johan, Thanks for fixing Luxemburg :) If you click on the relations of the Belgium Provinces on WikiProject_Belgium/Boundaries, you see that not all the Provinces are in admin_level 6, some of them are in 5. Oh well, that is their problem, as they find out that the address search is showing inconsistent data on their GPS, they will fix it eventually ;-) Johan wrote: in addition to Minko: according to http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries Belgium provinces should all be in admin_level 6 For Luxembourg: the cities are all in admin_level 8, the provinces (I think the Luxembourg name 'district' comes closest) are in admin_level 4 Cheers Johan

Hello, this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things... Cheers Martin Am 04.05.2011 um 21:03 schrieb WanMil:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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

Good morning :) Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?! Cheers Martin Am 05.05.2011 um 17:44 schrieb Martin:
Hello,
this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things...
Cheers Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Sorry, me again. I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile: 2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination] Where is the problem?! Are in the logfile are only not assignable streets logged?! Cheers Martin Am 06.05.2011 um 09:44 schrieb Martin:
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?!
Cheers Martin
Am 05.05.2011 um 17:44 schrieb Martin:
Hello,
this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things...
Cheers Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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
_______________________________________________ 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

Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar Can you please check if Horb is completely contained in one tile (63240403)? In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?! I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things. WanMil
Sorry, me again.
I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination]
Where is the problem?! Are in the logfile are only not assignable streets logged?!
Cheers Martin
Am 06.05.2011 um 09:44 schrieb Martin:
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?!
Cheers Martin
Am 05.05.2011 um 17:44 schrieb Martin:
Hello,
this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things...
Cheers Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=*& mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie But in level 5 you have something like the 'Flemish Community' too: http://www.openstreetmap.org/browse/relation/53136 There is also the Flemish region (level 4), don't have any clue what the difference is between those two: http://www.openstreetmap.org/browse/relation/53134
Cities: mkgmap:city!=*& mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
_______________________________________________ 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
_______________________________________________ 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

Hello, Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :) Cheers Martin P.S.: Isn't it possible to attach pictures to the maillist?! Am 06.05.2011 um 18:00 schrieb WanMil:
Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar
Can you please check if Horb is completely contained in one tile (63240403)?
In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?!
I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things.
WanMil
Sorry, me again.
I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination]
Where is the problem?! Are in the logfile are only not assignable streets logged?!
Cheers Martin
Am 06.05.2011 um 09:44 schrieb Martin:
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?!
Cheers Martin
Am 05.05.2011 um 17:44 schrieb Martin:
Hello,
this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things...
Cheers Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
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:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } 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_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> there are 2 options for the admin-boundaries: 10 and 11 admin levels :( So actually I still playing with this setting, maybe somebody has better rules for Germany.
Thanks and regards Martin
Am 04.05.2011 um 19:38 schrieb Minko:
> > Netherlands: > > mkgmap:region!=*& mkgmap:admin_level4=* { set > mkgmap:region='${mkgmap:admin_level4}' } > mkgmap:city!=*& mkgmap:admin_level10=* { set > mkgmap:city='${mkgmap:admin_level10}' } > mkgmap:city!=*& mkgmap:admin_level8=* { set > mkgmap:city='${mkgmap:admin_level8}' } > > For Belgium I'm not sure, seems a big mess there ;-) > > Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie > But in level 5 you have something like the 'Flemish Community' too: > http://www.openstreetmap.org/browse/relation/53136 > There is also the Flemish region (level 4), don't have any clue what > the difference is between those two: > http://www.openstreetmap.org/browse/relation/53134 > > Cities: > mkgmap:city!=*& mkgmap:admin_level9=* { set > mkgmap:city='${mkgmap:admin_level9}' } > mkgmap:city!=*& mkgmap:admin_level8=* { set > mkgmap:city='${mkgmap:admin_level8}' } > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Can you please send your areas.list from the splitter? Then I can test and debug myself. The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters. WanMil
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :)
Cheers Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar
Can you please check if Horb is completely contained in one tile (63240403)?
In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?!
I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things.
WanMil
Sorry, me again.
I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination]
Where is the problem?! Are in the logfile are only not assignable streets logged?!
Cheers Martin
Am 06.05.2011 um 09:44 schrieb Martin:
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?!
Cheers Martin
Am 05.05.2011 um 17:44 schrieb Martin:
Hello,
this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things...
Cheers Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a size up to 300000. Bigger cities don't use admin_level=8 but admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are committed in r1937.
Later on I will try your region settings.
WanMil
> In Germany we have the same mess... > > Actually I'm using this rules: > > 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:city!=*& mkgmap:admin_level10=* { set > mkgmap:city='${mkgmap:admin_level10}' } > 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_level6=* { set > mkgmap:city='${mkgmap:admin_level6}' } > > > I don't know if this makes sense, but referring to this page: > http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative > <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> > there are 2 options for the admin-boundaries: > 10 and 11 admin levels :( > So actually I still playing with this setting, maybe somebody has better > rules for Germany. > > > Thanks and regards > Martin > > > Am 04.05.2011 um 19:38 schrieb Minko: > >> >> Netherlands: >> >> mkgmap:region!=*& mkgmap:admin_level4=* { set >> mkgmap:region='${mkgmap:admin_level4}' } >> mkgmap:city!=*& mkgmap:admin_level10=* { set >> mkgmap:city='${mkgmap:admin_level10}' } >> mkgmap:city!=*& mkgmap:admin_level8=* { set >> mkgmap:city='${mkgmap:admin_level8}' } >> >> For Belgium I'm not sure, seems a big mess there ;-) >> >> Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie >> But in level 5 you have something like the 'Flemish Community' too: >> http://www.openstreetmap.org/browse/relation/53136 >> There is also the Flemish region (level 4), don't have any clue what >> the difference is between those two: >> http://www.openstreetmap.org/browse/relation/53134 >> >> Cities: >> mkgmap:city!=*& mkgmap:admin_level9=* { set >> mkgmap:city='${mkgmap:admin_level9}' } >> mkgmap:city!=*& mkgmap:admin_level8=* { set >> mkgmap:city='${mkgmap:admin_level8}' } >> >> _______________________________________________ >> 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
_______________________________________________ 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
_______________________________________________ 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

Hello WanMil, please find attached the area.list-file. I use the following command: java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP Cheers Martin Am 07.05.2011 um 13:45 schrieb WanMil:
Can you please send your areas.list from the splitter? Then I can test and debug myself.
The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters.
WanMil
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :)
Cheers Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar
Can you please check if Horb is completely contained in one tile (63240403)?
In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?!
I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things.
WanMil
Sorry, me again.
I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination]
Where is the problem?! Are in the logfile are only not assignable streets logged?!
Cheers Martin
Am 06.05.2011 um 09:44 schrieb Martin:
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?!
Cheers Martin
Am 05.05.2011 um 17:44 schrieb Martin:
Hello,
this rules works very good. 2 strange things: Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). And the second thing: I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... Strange things...
Cheers Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
> I think only the city rules need to be tweaked in Germany: > > # Germany = DEU cities > mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set > mkgmap:city='${mkgmap:admin_level8}' } > mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set > mkgmap:city='${mkgmap:admin_level7}' } > mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set > mkgmap:city='${mkgmap:admin_level6}' } > mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set > mkgmap:city='${mkgmap:admin_level9}' } > mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set > mkgmap:city='${mkgmap:admin_level10}' } > > First use admin_level=8 for city names. This covers all cities with a > size up to 300000. Bigger cities don't use admin_level=8 but > admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the > bigger city should be contained then in the admin_level 7 or 6. > > Please try it and give a feedback if that's ok. The upper rules are > committed in r1937. > > Later on I will try your region settings. > > WanMil > >> In Germany we have the same mess... >> >> Actually I'm using this rules: >> >> 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:city!=*& mkgmap:admin_level10=* { set >> mkgmap:city='${mkgmap:admin_level10}' } >> 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_level6=* { set >> mkgmap:city='${mkgmap:admin_level6}' } >> >> >> I don't know if this makes sense, but referring to this page: >> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative >> <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> >> there are 2 options for the admin-boundaries: >> 10 and 11 admin levels :( >> So actually I still playing with this setting, maybe somebody has better >> rules for Germany. >> >> >> Thanks and regards >> Martin >> >> >> Am 04.05.2011 um 19:38 schrieb Minko: >> >>> >>> Netherlands: >>> >>> mkgmap:region!=*& mkgmap:admin_level4=* { set >>> mkgmap:region='${mkgmap:admin_level4}' } >>> mkgmap:city!=*& mkgmap:admin_level10=* { set >>> mkgmap:city='${mkgmap:admin_level10}' } >>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>> mkgmap:city='${mkgmap:admin_level8}' } >>> >>> For Belgium I'm not sure, seems a big mess there ;-) >>> >>> Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie >>> But in level 5 you have something like the 'Flemish Community' too: >>> http://www.openstreetmap.org/browse/relation/53136 >>> There is also the Flemish region (level 4), don't have any clue what >>> the difference is between those two: >>> http://www.openstreetmap.org/browse/relation/53134 >>> >>> Cities: >>> mkgmap:city!=*& mkgmap:admin_level9=* { set >>> mkgmap:city='${mkgmap:admin_level9}' } >>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>> mkgmap:city='${mkgmap:admin_level8}' } >>> >>> _______________________________________________ >>> 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 >
_______________________________________________ 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
_______________________________________________ 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

Martin, I cannot reproduce your problem but possibly that's because I misunderstood you. I splitted the geofabrik germany dump using your areas.list and then started mkgmap with your command line parameters. After that without any modification of the original OSM data I can find the street "Schafblumenhalde" (just search for the street name). The find dialog tells me that it is located in the town "Horb am Neckar" in region "Landkreis Freudenstadt" and country "DEU". So far so fine! But when I enter the city in the search dialog the street is not found any more. This should not be a problem of the locator branch but a more general problem with the index creation. Maybe Steve can have a look on it. WanMil
Hello WanMil,
please find attached the area.list-file. I use the following command: java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP
Cheers Martin
Am 07.05.2011 um 13:45 schrieb WanMil:
Can you please send your areas.list from the splitter? Then I can test and debug myself.
The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters.
WanMil
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :)
Cheers Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar
Can you please check if Horb is completely contained in one tile (63240403)?
In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?!
I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things.
WanMil
Sorry, me again.
I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination]
Where is the problem?! Are in the logfile are only not assignable streets logged?!
Cheers Martin
Am 06.05.2011 um 09:44 schrieb Martin:
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. Is it possible, that this problem comes from the splitter?!
Cheers Martin
Am 05.05.2011 um 17:44 schrieb Martin:
> Hello, > > this rules works very good. 2 strange things: > Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). > And the second thing: > I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) > But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... > Strange things... > > Cheers > Martin > > > > > Am 04.05.2011 um 21:03 schrieb WanMil: > >> I think only the city rules need to be tweaked in Germany: >> >> # Germany = DEU cities >> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set >> mkgmap:city='${mkgmap:admin_level8}' } >> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set >> mkgmap:city='${mkgmap:admin_level7}' } >> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set >> mkgmap:city='${mkgmap:admin_level6}' } >> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set >> mkgmap:city='${mkgmap:admin_level9}' } >> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set >> mkgmap:city='${mkgmap:admin_level10}' } >> >> First use admin_level=8 for city names. This covers all cities with a >> size up to 300000. Bigger cities don't use admin_level=8 but >> admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the >> bigger city should be contained then in the admin_level 7 or 6. >> >> Please try it and give a feedback if that's ok. The upper rules are >> committed in r1937. >> >> Later on I will try your region settings. >> >> WanMil >> >>> In Germany we have the same mess... >>> >>> Actually I'm using this rules: >>> >>> 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:city!=*& mkgmap:admin_level10=* { set >>> mkgmap:city='${mkgmap:admin_level10}' } >>> 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_level6=* { set >>> mkgmap:city='${mkgmap:admin_level6}' } >>> >>> >>> I don't know if this makes sense, but referring to this page: >>> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative >>> <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> >>> there are 2 options for the admin-boundaries: >>> 10 and 11 admin levels :( >>> So actually I still playing with this setting, maybe somebody has better >>> rules for Germany. >>> >>> >>> Thanks and regards >>> Martin >>> >>> >>> Am 04.05.2011 um 19:38 schrieb Minko: >>> >>>> >>>> Netherlands: >>>> >>>> mkgmap:region!=*& mkgmap:admin_level4=* { set >>>> mkgmap:region='${mkgmap:admin_level4}' } >>>> mkgmap:city!=*& mkgmap:admin_level10=* { set >>>> mkgmap:city='${mkgmap:admin_level10}' } >>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>> mkgmap:city='${mkgmap:admin_level8}' } >>>> >>>> For Belgium I'm not sure, seems a big mess there ;-) >>>> >>>> Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie >>>> But in level 5 you have something like the 'Flemish Community' too: >>>> http://www.openstreetmap.org/browse/relation/53136 >>>> There is also the Flemish region (level 4), don't have any clue what >>>> the difference is between those two: >>>> http://www.openstreetmap.org/browse/relation/53134 >>>> >>>> Cities: >>>> mkgmap:city!=*& mkgmap:admin_level9=* { set >>>> mkgmap:city='${mkgmap:admin_level9}' } >>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>> mkgmap:city='${mkgmap:admin_level8}' } >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Have you searched for the street on a Garmin Device or in Mapsource/Basecamp? When I search it on my Oregon without a City, I find the street, but when I select this street, there is no location found (N --°---- E --°------). It seems, that the index-file creates a entry for this street, but then... something breaks. But when you copy the place-tag of horb into the tile, everythings works fine... Am 07.05.2011 um 21:13 schrieb WanMil:
Martin,
I cannot reproduce your problem but possibly that's because I misunderstood you. I splitted the geofabrik germany dump using your areas.list and then started mkgmap with your command line parameters.
After that without any modification of the original OSM data I can find the street "Schafblumenhalde" (just search for the street name). The find dialog tells me that it is located in the town "Horb am Neckar" in region "Landkreis Freudenstadt" and country "DEU". So far so fine!
But when I enter the city in the search dialog the street is not found any more. This should not be a problem of the locator branch but a more general problem with the index creation. Maybe Steve can have a look on it.
WanMil
Hello WanMil,
please find attached the area.list-file. I use the following command: java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP
Cheers Martin
Am 07.05.2011 um 13:45 schrieb WanMil:
Can you please send your areas.list from the splitter? Then I can test and debug myself.
The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters.
WanMil
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :)
Cheers Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar
Can you please check if Horb is completely contained in one tile (63240403)?
In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?!
I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things.
WanMil
Sorry, me again.
I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination]
Where is the problem?! Are in the logfile are only not assignable streets logged?!
Cheers Martin
Am 06.05.2011 um 09:44 schrieb Martin:
> Good morning :) > > Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. > Is it possible, that this problem comes from the splitter?! > > Cheers > Martin > > > Am 05.05.2011 um 17:44 schrieb Martin: > >> Hello, >> >> this rules works very good. 2 strange things: >> Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). >> And the second thing: >> I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) >> But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... >> Strange things... >> >> Cheers >> Martin >> >> >> >> >> Am 04.05.2011 um 21:03 schrieb WanMil: >> >>> I think only the city rules need to be tweaked in Germany: >>> >>> # Germany = DEU cities >>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set >>> mkgmap:city='${mkgmap:admin_level8}' } >>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set >>> mkgmap:city='${mkgmap:admin_level7}' } >>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set >>> mkgmap:city='${mkgmap:admin_level6}' } >>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set >>> mkgmap:city='${mkgmap:admin_level9}' } >>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set >>> mkgmap:city='${mkgmap:admin_level10}' } >>> >>> First use admin_level=8 for city names. This covers all cities with a >>> size up to 300000. Bigger cities don't use admin_level=8 but >>> admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the >>> bigger city should be contained then in the admin_level 7 or 6. >>> >>> Please try it and give a feedback if that's ok. The upper rules are >>> committed in r1937. >>> >>> Later on I will try your region settings. >>> >>> WanMil >>> >>>> In Germany we have the same mess... >>>> >>>> Actually I'm using this rules: >>>> >>>> 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:city!=*& mkgmap:admin_level10=* { set >>>> mkgmap:city='${mkgmap:admin_level10}' } >>>> 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_level6=* { set >>>> mkgmap:city='${mkgmap:admin_level6}' } >>>> >>>> >>>> I don't know if this makes sense, but referring to this page: >>>> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative >>>> <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> >>>> there are 2 options for the admin-boundaries: >>>> 10 and 11 admin levels :( >>>> So actually I still playing with this setting, maybe somebody has better >>>> rules for Germany. >>>> >>>> >>>> Thanks and regards >>>> Martin >>>> >>>> >>>> Am 04.05.2011 um 19:38 schrieb Minko: >>>> >>>>> >>>>> Netherlands: >>>>> >>>>> mkgmap:region!=*& mkgmap:admin_level4=* { set >>>>> mkgmap:region='${mkgmap:admin_level4}' } >>>>> mkgmap:city!=*& mkgmap:admin_level10=* { set >>>>> mkgmap:city='${mkgmap:admin_level10}' } >>>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>> >>>>> For Belgium I'm not sure, seems a big mess there ;-) >>>>> >>>>> Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie >>>>> But in level 5 you have something like the 'Flemish Community' too: >>>>> http://www.openstreetmap.org/browse/relation/53136 >>>>> There is also the Flemish region (level 4), don't have any clue what >>>>> the difference is between those two: >>>>> http://www.openstreetmap.org/browse/relation/53134 >>>>> >>>>> Cities: >>>>> mkgmap:city!=*& mkgmap:admin_level9=* { set >>>>> mkgmap:city='${mkgmap:admin_level9}' } >>>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> 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
_______________________________________________ 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
_______________________________________________ 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 used Mapsource.
Have you searched for the street on a Garmin Device or in Mapsource/Basecamp? When I search it on my Oregon without a City, I find the street, but when I select this street, there is no location found (N --°---- E --°------). It seems, that the index-file creates a entry for this street, but then... something breaks. But when you copy the place-tag of horb into the tile, everythings works fine...
Am 07.05.2011 um 21:13 schrieb WanMil:
Martin,
I cannot reproduce your problem but possibly that's because I misunderstood you. I splitted the geofabrik germany dump using your areas.list and then started mkgmap with your command line parameters.
After that without any modification of the original OSM data I can find the street "Schafblumenhalde" (just search for the street name). The find dialog tells me that it is located in the town "Horb am Neckar" in region "Landkreis Freudenstadt" and country "DEU". So far so fine!
But when I enter the city in the search dialog the street is not found any more. This should not be a problem of the locator branch but a more general problem with the index creation. Maybe Steve can have a look on it.
WanMil
Hello WanMil,
please find attached the area.list-file. I use the following command: java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP
Cheers Martin
Am 07.05.2011 um 13:45 schrieb WanMil:
Can you please send your areas.list from the splitter? Then I can test and debug myself.
The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters.
WanMil
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :)
Cheers Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar
Can you please check if Horb is completely contained in one tile (63240403)?
In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?!
I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things.
WanMil
> Sorry, me again. > > I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile: > > 2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination] > > > Where is the problem?! > Are in the logfile are only not assignable streets logged?! > > Cheers > Martin > > Am 06.05.2011 um 09:44 schrieb Martin: > >> Good morning :) >> >> Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. >> Is it possible, that this problem comes from the splitter?! >> >> Cheers >> Martin >> >> >> Am 05.05.2011 um 17:44 schrieb Martin: >> >>> Hello, >>> >>> this rules works very good. 2 strange things: >>> Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). >>> And the second thing: >>> I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) >>> But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... >>> Strange things... >>> >>> Cheers >>> Martin >>> >>> >>> >>> >>> Am 04.05.2011 um 21:03 schrieb WanMil: >>> >>>> I think only the city rules need to be tweaked in Germany: >>>> >>>> # Germany = DEU cities >>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set >>>> mkgmap:city='${mkgmap:admin_level8}' } >>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set >>>> mkgmap:city='${mkgmap:admin_level7}' } >>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set >>>> mkgmap:city='${mkgmap:admin_level6}' } >>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set >>>> mkgmap:city='${mkgmap:admin_level9}' } >>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set >>>> mkgmap:city='${mkgmap:admin_level10}' } >>>> >>>> First use admin_level=8 for city names. This covers all cities with a >>>> size up to 300000. Bigger cities don't use admin_level=8 but >>>> admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the >>>> bigger city should be contained then in the admin_level 7 or 6. >>>> >>>> Please try it and give a feedback if that's ok. The upper rules are >>>> committed in r1937. >>>> >>>> Later on I will try your region settings. >>>> >>>> WanMil >>>> >>>>> In Germany we have the same mess... >>>>> >>>>> Actually I'm using this rules: >>>>> >>>>> 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:city!=*& mkgmap:admin_level10=* { set >>>>> mkgmap:city='${mkgmap:admin_level10}' } >>>>> 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_level6=* { set >>>>> mkgmap:city='${mkgmap:admin_level6}' } >>>>> >>>>> >>>>> I don't know if this makes sense, but referring to this page: >>>>> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative >>>>> <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> >>>>> there are 2 options for the admin-boundaries: >>>>> 10 and 11 admin levels :( >>>>> So actually I still playing with this setting, maybe somebody has better >>>>> rules for Germany. >>>>> >>>>> >>>>> Thanks and regards >>>>> Martin >>>>> >>>>> >>>>> Am 04.05.2011 um 19:38 schrieb Minko: >>>>> >>>>>> >>>>>> Netherlands: >>>>>> >>>>>> mkgmap:region!=*& mkgmap:admin_level4=* { set >>>>>> mkgmap:region='${mkgmap:admin_level4}' } >>>>>> mkgmap:city!=*& mkgmap:admin_level10=* { set >>>>>> mkgmap:city='${mkgmap:admin_level10}' } >>>>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>>> >>>>>> For Belgium I'm not sure, seems a big mess there ;-) >>>>>> >>>>>> Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie >>>>>> But in level 5 you have something like the 'Flemish Community' too: >>>>>> http://www.openstreetmap.org/browse/relation/53136 >>>>>> There is also the Flemish region (level 4), don't have any clue what >>>>>> the difference is between those two: >>>>>> http://www.openstreetmap.org/browse/relation/53134 >>>>>> >>>>>> Cities: >>>>>> mkgmap:city!=*& mkgmap:admin_level9=* { set >>>>>> mkgmap:city='${mkgmap:admin_level9}' } >>>>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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
_______________________________________________ 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
_______________________________________________ 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

Funny thing, because you can find the street in Mapsource, but in Basecamp it won't work. I've downloaded a new german-snapshot from geofabric and with the arealist I get the same problem. On my Garmin I can find the street, but the device isn't able to show it on the map. (http://snailrun.de/images/MapSearch/3.jpg, http://snailrun.de/images/MapSearch/4.jpg) Hope Steve hat some time to look on this problem/challenge :) Cheers Martin Am 07.05.2011 um 21:35 schrieb WanMil:
I have used Mapsource.
Have you searched for the street on a Garmin Device or in Mapsource/Basecamp? When I search it on my Oregon without a City, I find the street, but when I select this street, there is no location found (N --°---- E --°------). It seems, that the index-file creates a entry for this street, but then... something breaks. But when you copy the place-tag of horb into the tile, everythings works fine...
Am 07.05.2011 um 21:13 schrieb WanMil:
Martin,
I cannot reproduce your problem but possibly that's because I misunderstood you. I splitted the geofabrik germany dump using your areas.list and then started mkgmap with your command line parameters.
After that without any modification of the original OSM data I can find the street "Schafblumenhalde" (just search for the street name). The find dialog tells me that it is located in the town "Horb am Neckar" in region "Landkreis Freudenstadt" and country "DEU". So far so fine!
But when I enter the city in the search dialog the street is not found any more. This should not be a problem of the locator branch but a more general problem with the index creation. Maybe Steve can have a look on it.
WanMil
Hello WanMil,
please find attached the area.list-file. I use the following command: java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP
Cheers Martin
Am 07.05.2011 um 13:45 schrieb WanMil:
Can you please send your areas.list from the splitter? Then I can test and debug myself.
The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters.
WanMil
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :)
Cheers Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
> Based on the logging and the current default style I would expect that > you get a street with > name = Schafblumenhalde > country = Deutschland > region = Landkreis Freudenstadt > city = Horb am Neckar > > Can you please check if Horb is completely contained in one tile (63240403)? > > In that case I would assume that maybe this is an index problem. Maybe > Steve is able to check that?! > > I will continue to add some more useful debug statements to the locator > branch so that it is easier to track such things. > > WanMil > >> Sorry, me again. >> >> I used now the tile produced the splitter, which contains the the not found streets of Horb. For e.g. I could find the Schafblumenhalde. With the debug-logging (LocationHook = FINE) I find this in the logfile: >> >> 2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk Karlsruhe,mkgmap:admin_level6=Landkreis Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am Neckar,highway=residential,motorcar=destination] >> >> >> Where is the problem?! >> Are in the logfile are only not assignable streets logged?! >> >> Cheers >> Martin >> >> Am 06.05.2011 um 09:44 schrieb Martin: >> >>> Good morning :) >>> >>> Both problems didn't come up, when I cut a small bounding box out of the main pbf-file with osmosis and create a map with just this one tile. >>> Is it possible, that this problem comes from the splitter?! >>> >>> Cheers >>> Martin >>> >>> >>> Am 05.05.2011 um 17:44 schrieb Martin: >>> >>>> Hello, >>>> >>>> this rules works very good. 2 strange things: >>>> Sometimes Basecamp and the Oregon 450 has problems to find Streets starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem with the Umlaute (äöü). >>>> And the second thing: >>>> I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted into tiles with a 1200000 nodes. In Horb for example I can find the "Am Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde (http://osm.org/go/0DhcL1dyJ-?way=22999129) >>>> But when I cut out a bounding-box from the Germany.osm.pfb-file in the size of Horb, I can find the all streets.... >>>> Strange things... >>>> >>>> Cheers >>>> Martin >>>> >>>> >>>> >>>> >>>> Am 04.05.2011 um 21:03 schrieb WanMil: >>>> >>>>> I think only the city rules need to be tweaked in Germany: >>>>> >>>>> # Germany = DEU cities >>>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set >>>>> mkgmap:city='${mkgmap:admin_level7}' } >>>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set >>>>> mkgmap:city='${mkgmap:admin_level6}' } >>>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set >>>>> mkgmap:city='${mkgmap:admin_level9}' } >>>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set >>>>> mkgmap:city='${mkgmap:admin_level10}' } >>>>> >>>>> First use admin_level=8 for city names. This covers all cities with a >>>>> size up to 300000. Bigger cities don't use admin_level=8 but >>>>> admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the >>>>> bigger city should be contained then in the admin_level 7 or 6. >>>>> >>>>> Please try it and give a feedback if that's ok. The upper rules are >>>>> committed in r1937. >>>>> >>>>> Later on I will try your region settings. >>>>> >>>>> WanMil >>>>> >>>>>> In Germany we have the same mess... >>>>>> >>>>>> Actually I'm using this rules: >>>>>> >>>>>> 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:city!=*& mkgmap:admin_level10=* { set >>>>>> mkgmap:city='${mkgmap:admin_level10}' } >>>>>> 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_level6=* { set >>>>>> mkgmap:city='${mkgmap:admin_level6}' } >>>>>> >>>>>> >>>>>> I don't know if this makes sense, but referring to this page: >>>>>> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative >>>>>> <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative> >>>>>> there are 2 options for the admin-boundaries: >>>>>> 10 and 11 admin levels :( >>>>>> So actually I still playing with this setting, maybe somebody has better >>>>>> rules for Germany. >>>>>> >>>>>> >>>>>> Thanks and regards >>>>>> Martin >>>>>> >>>>>> >>>>>> Am 04.05.2011 um 19:38 schrieb Minko: >>>>>> >>>>>>> >>>>>>> Netherlands: >>>>>>> >>>>>>> mkgmap:region!=*& mkgmap:admin_level4=* { set >>>>>>> mkgmap:region='${mkgmap:admin_level4}' } >>>>>>> mkgmap:city!=*& mkgmap:admin_level10=* { set >>>>>>> mkgmap:city='${mkgmap:admin_level10}' } >>>>>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>>>> >>>>>>> For Belgium I'm not sure, seems a big mess there ;-) >>>>>>> >>>>>>> Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie >>>>>>> But in level 5 you have something like the 'Flemish Community' too: >>>>>>> http://www.openstreetmap.org/browse/relation/53136 >>>>>>> There is also the Flemish region (level 4), don't have any clue what >>>>>>> the difference is between those two: >>>>>>> http://www.openstreetmap.org/browse/relation/53134 >>>>>>> >>>>>>> Cities: >>>>>>> mkgmap:city!=*& mkgmap:admin_level9=* { set >>>>>>> mkgmap:city='${mkgmap:admin_level9}' } >>>>>>> mkgmap:city!=*& mkgmap:admin_level8=* { set >>>>>>> mkgmap:city='${mkgmap:admin_level8}' } >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden. In the style file maybe this is possible? mkgmap:country=NLD & highway=trunk {add bicycle=no}

Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}
Yes, you can :-) WanMil

Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html Example: leisure=pitch & sport=soccer & (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch & sport=soccer & mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch & sport=soccer & (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch & sport=soccer [0x19 resolution 23] "Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role. ---------- Wanmil wrote:
Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}
Yes, you can :-) WanMil

El 16/05/11 19:27, Minko escribió:
Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example: leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary & (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig?
"Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role.
---------- Wanmil wrote:
Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}

El 16/05/11 19:27, Minko escribió:
Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example: leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig?
It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml.
"Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role.
---------- Wanmil wrote:
Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}

El 19/05/11 21:29, WanMil escribió:
El 16/05/11 19:27, Minko escribió:
Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example: leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig? It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar.
"Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role.
---------- Wanmil wrote:
Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}
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.

El 19/05/11 21:29, WanMil escribió:
El 16/05/11 19:27, Minko escribió:
Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example: leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig? It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar.
Oh, I am sorry. I mixed up some things. Do you use the default-country parameter? Do you have other maps installed in MapSource? I have no idea at the moment why Morocco is abbreviated with MOR but I will test that myself. WanMil
"Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role.
---------- Wanmil wrote:
Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}

El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escribió:
El 16/05/11 19:27, Minko escribió:
Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example: leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig? It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar. Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)" Do you use the default-country parameter? Using --country-name=MOROCCO Do you have other maps installed in MapSource? Yes, more than 15 I have no idea at the moment why Morocco is abbreviated with MOR but I will test that myself.
WanMil
"Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role.
---------- Wanmil wrote:
Just wondering, maybe we can use the locator rules also for country or state specific routing? For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}
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.

El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escribió:
El 16/05/11 19:27, Minko escribió:
Cool! I can use these locator rules also for the multiple language expressions in the 'default_name': http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example: leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig? It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar. Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)"
That's good because this question is answered :-) The style can work only if the boundaries of Morocco are contained in the precompiled boundary tiles. I think my europe compilation may contain a small part of northern morocco. So you should do the following steps: 1. Check that the boundary multipolygon of Morocco is complete and valid 2. Precompile the boundary tiles 3. Compile your map again using the precompiled boundary tiles Then the style rules should work. WanMil
Do you use the default-country parameter? Using --country-name=MOROCCO Do you have other maps installed in MapSource? Yes, more than 15 I have no idea at the moment why Morocco is abbreviated with MOR but I will test that myself.
WanMil
"Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role.
---------- Wanmil wrote:
> Just wondering, maybe we can use the locator rules also for country or state specific routing? > For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden. > > In the style file maybe this is possible? > > mkgmap:country=NLD& highway=trunk {add bicycle=no}
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

El 19/05/11 23:15, WanMil escribió:
El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escribió:
El 16/05/11 19:27, Minko escribió: > Cool! > I can use these locator rules also for the multiple language expressions in the 'default_name': > http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html > > Example: > leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] > leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] > leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] > leisure=pitch& sport=soccer [0x19 resolution 23] I tried rules of type below, but it doesn't work for Morocco. highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16] highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although LocatorConfig.xml has the rule below and there's no occurrence of "MOR" in the OSM data. <country name="Morocco" abr="MAR"> <variant>MA</variant> <variant>MAR</variant> </country> I know I could use MOR instead of MAR in my style but, shouldn't it be consistent with the LocatorConfig? It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar. Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)" That's good because this question is answered :-)
The style can work only if the boundaries of Morocco are contained in the precompiled boundary tiles. I think my europe compilation may contain a small part of northern morocco. So you should do the following steps: 1. Check that the boundary multipolygon of Morocco is complete and valid 2. Precompile the boundary tiles 3. Compile your map again using the precompiled boundary tiles
Then the style rules should work. I had already compiled Morocco's boundary (extracted from Geofabrik morocco.osm.pbf). What I didn't is converting bnd to gpx and checking it, but that will be tomorrow... PS: I tried to compile boundaries for all Africa, but there were errors and it didn't complete. I fixed most multipolygon (boundary) errors found in log and will try again tomorrow. As soon as I succeed I will make them available. WanMil
Do you use the default-country parameter? Using --country-name=MOROCCO Do you have other maps installed in MapSource? Yes, more than 15 I have no idea at the moment why Morocco is abbreviated with MOR but I will test that myself.
WanMil
> "Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role. > > ---------- > Wanmil wrote: > >> Just wondering, maybe we can use the locator rules also for country or state specific routing? >> For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden. >> >> In the style file maybe this is possible? >> >> mkgmap:country=NLD& highway=trunk {add bicycle=no}
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.

El 20/05/11 00:07, Carlos Dávila escribió:
PS: I tried to compile boundaries for all Africa, but there were errors and it didn't complete. I fixed most multipolygon (boundary) errors found in log and will try again tomorrow. As soon as I succeed I will make them available. It still fails today with the same error: Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.boundary.BoundarySaver.end(BoundarySaver.java:74) at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreparer.run(BoundaryPreparer.java:99) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:353) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132)
Log shows thousands of messages like this: GRAVE (BoundarySaver): r1562048: Cannot save boundary: java.io.FileNotFoundException: bounds_africa/bounds_-100000_1700000.bnd (Too many open files) How to fix them? Last messages in log are: ADVERTENCIA (BoundarySaver): r1562048: Do not use bonding box because it's empty GRAVE (BoundarySaver): r1562048: Calculate bbox to (-35.40515899658203,-18.23902130126953) to (37.550926208496094,55.789947509765625)

El 20/05/11 00:07, Carlos Dávila escribió:
PS: I tried to compile boundaries for all Africa, but there were errors and it didn't complete. I fixed most multipolygon (boundary) errors found in log and will try again tomorrow. As soon as I succeed I will make them available. It still fails today with the same error: Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.boundary.BoundarySaver.end(BoundarySaver.java:74) at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreparer.run(BoundaryPreparer.java:99) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:353) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132)
Log shows thousands of messages like this: GRAVE (BoundarySaver): r1562048: Cannot save boundary: java.io.FileNotFoundException: bounds_africa/bounds_-100000_1700000.bnd (Too many open files) How to fix them? Last messages in log are: ADVERTENCIA (BoundarySaver): r1562048: Do not use bonding box because it's empty GRAVE (BoundarySaver): r1562048: Calculate bbox to (-35.40515899658203,-18.23902130126953) to (37.550926208496094,55.789947509765625)
r1952 should fix the Exception. The precompiler openend too much files at the same time. Now it is limited to 100. WanMil

El 20/05/11 18:53, WanMil escribió:
El 20/05/11 00:07, Carlos Dávila escribió:
PS: I tried to compile boundaries for all Africa, but there were errors and it didn't complete. I fixed most multipolygon (boundary) errors found in log and will try again tomorrow. As soon as I succeed I will make them available. It still fails today with the same error: Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.boundary.BoundarySaver.end(BoundarySaver.java:74) at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreparer.run(BoundaryPreparer.java:99) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:353) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132)
Log shows thousands of messages like this: GRAVE (BoundarySaver): r1562048: Cannot save boundary: java.io.FileNotFoundException: bounds_africa/bounds_-100000_1700000.bnd (Too many open files) How to fix them? Last messages in log are: ADVERTENCIA (BoundarySaver): r1562048: Do not use bonding box because it's empty GRAVE (BoundarySaver): r1562048: Calculate bbox to (-35.40515899658203,-18.23902130126953) to (37.550926208496094,55.789947509765625) r1952 should fix the Exception. The precompiler openend too much files at the same time. Now it is limited to 100. Now it compiled straightforward. Great! For those interested, boundaries are available at http://mapas.alternativaslibres.es/bounds_africa_20110520.zip

El 20/05/11 00:07, Carlos Dávila escribió:
El 19/05/11 23:15, WanMil escribió:
El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escribió:
> El 16/05/11 19:27, Minko escribió: >> Cool! >> I can use these locator rules also for the multiple language expressions in the 'default_name': >> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html >> >> Example: >> leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] >> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] >> leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] >> leisure=pitch& sport=soccer [0x19 resolution 23] > I tried rules of type below, but it doesn't work for Morocco. > highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 > road_class=3 road_speed=5 resolution 16] > highway=primary [0x03 road_class=3 road_speed=5 resolution 18] > > MapSouce shows "Morocco (MOR)" in the countries list, although > LocatorConfig.xml has the rule below and there's no occurrence of "MOR" > in the OSM data. > <country name="Morocco" abr="MAR"> > <variant>MA</variant> > <variant>MAR</variant> > </country> > I know I could use MOR instead of MAR in my style but, shouldn't it be > consistent with the LocatorConfig? It seems as if the LocatorConfig you changed is not used by mkgmap. Do you use a downloaded mkgmap.jar? I am not sure where your changed LocatorConfig.xml must be placed so that mkgmap does not use the bundled LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar. Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)" That's good because this question is answered :-)
The style can work only if the boundaries of Morocco are contained in the precompiled boundary tiles. I think my europe compilation may contain a small part of northern morocco. So you should do the following steps: 1. Check that the boundary multipolygon of Morocco is complete and valid 2. Precompile the boundary tiles 3. Compile your map again using the precompiled boundary tiles
Then the style rules should work. I had already compiled Morocco's boundary (extracted from Geofabrik morocco.osm.pbf). What I didn't is converting bnd to gpx and checking it, but that will be tomorrow... I checked part of the bound tiles and they are correct. Here are all my steps, so you can see if I'm doing something wrong: 1-Extract boundaries: osmosis \ --read-pbf file=morocco.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=morocco-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
2-Map compilation: time /usr/lib/jvm/java-6-sun/bin/java -Xmx400m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=morocco-boundaries.osm.pbf --boundsdirectory=bounds_morocco --generate-sea=extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --description="OpenStreetMap-Morocco" --gmapsupp --country-name=MOROCCO --country-abbr=MAR --family-name="Open Street Map" --family-id=17 --product-id=1 --series-name="OSM-Morocco" --area-name="Morocco" --overview-mapname=55170000 --mapname=55170000 --name-tag-list=int_name,name --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --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 typ/MOROC-17.TYP morocco.osm.pbf
PS: I tried to compile boundaries for all Africa, but there were errors and it didn't complete. I fixed most multipolygon (boundary) errors found in log and will try again tomorrow. As soon as I succeed I will make them available.
WanMil
Do you use the default-country parameter? Using --country-name=MOROCCO Do you have other maps installed in MapSource? Yes, more than 15 I have no idea at the moment why Morocco is abbreviated with MOR but I will test that myself.
WanMil
>> "Région Wallone" is however not recognised, maybe the relation 90348 is not complete? JOSM is complaining about a few members without role. >> >> ---------- >> Wanmil wrote: >> >>> Just wondering, maybe we can use the locator rules also for country or state specific routing? >>> For instance in some countries (like Germany (?) according to the access rules on osm, see http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#...) one is allowed to cycle on trunk roads, while in other countries like in the Netherlands this is forbidden. >>> >>> In the style file maybe this is possible? >>> >>> mkgmap:country=NLD& highway=trunk {add bicycle=no}
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.

El 20/05/11 11:06, Carlos Dávila escribió:
El 20/05/11 00:07, Carlos Dávila escribió:
El 19/05/11 23:15, WanMil escribió:
El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escribió: >> El 16/05/11 19:27, Minko escribió: >>> Cool! >>> I can use these locator rules also for the multiple language expressions in the 'default_name': >>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html >>> >>> Example: >>> leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] >>> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] >>> leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] >>> leisure=pitch& sport=soccer [0x19 resolution 23] >> I tried rules of type below, but it doesn't work for Morocco. >> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 >> road_class=3 road_speed=5 resolution 16] >> highway=primary [0x03 road_class=3 road_speed=5 resolution 18] >> >> MapSouce shows "Morocco (MOR)" in the countries list, although >> LocatorConfig.xml has the rule below and there's no occurrence of "MOR" >> in the OSM data. >> <country name="Morocco" abr="MAR"> >> <variant>MA</variant> >> <variant>MAR</variant> >> </country> >> I know I could use MOR instead of MAR in my style but, shouldn't it be >> consistent with the LocatorConfig? > It seems as if the LocatorConfig you changed is not used by mkgmap. Do > you use a downloaded mkgmap.jar? I am not sure where your changed > LocatorConfig.xml must be placed so that mkgmap does not use the bundled > LocatorConfig.xml. I have not changed LocatorConfig.xml, I'm using the default one. I use a self compiled jar. Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)" That's good because this question is answered :-)
The style can work only if the boundaries of Morocco are contained in the precompiled boundary tiles. I think my europe compilation may contain a small part of northern morocco. So you should do the following steps: 1. Check that the boundary multipolygon of Morocco is complete and valid 2. Precompile the boundary tiles 3. Compile your map again using the precompiled boundary tiles
Then the style rules should work. I had already compiled Morocco's boundary (extracted from Geofabrik morocco.osm.pbf). What I didn't is converting bnd to gpx and checking it, but that will be tomorrow... I checked part of the bound tiles and they are correct. Here are all my steps, so you can see if I'm doing something wrong: 1-Extract boundaries: osmosis \ --read-pbf file=morocco.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=morocco-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
2-Map compilation: time /usr/lib/jvm/java-6-sun/bin/java -Xmx400m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=morocco-boundaries.osm.pbf --boundsdirectory=bounds_morocco --generate-sea=extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --description="OpenStreetMap-Morocco" --gmapsupp --country-name=MOROCCO --country-abbr=MAR --family-name="Open Street Map" --family-id=17 --product-id=1 --series-name="OSM-Morocco" --area-name="Morocco" --overview-mapname=55170000 --mapname=55170000 --name-tag-list=int_name,name --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --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 typ/MOROC-17.TYP morocco.osm.pbf I've seen streets/roads don't have city, region, country information assigned in my Morocco's map when searched in MapSource. As there's no city boundary and nearly no region boundary in OSM data mkgmap:region!=* and mkgmap:city!=* rules in style fail to fill that info and this seems to block country info to be assigned even if it is present. I have tuned style to assign a default city and region when missing and then country is correctly set (and also region if present), but even so, rule "highway=primary & (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16]" is not applied.

Am 21.05.2011 19:45, schrieb Carlos Dávila:
El 20/05/11 11:06, Carlos Dávila escribió:
El 20/05/11 00:07, Carlos Dávila escribió:
El 19/05/11 23:15, WanMil escribió:
El 19/05/11 22:12, WanMil escribió:
> El 19/05/11 21:29, WanMil escribió: >>> El 16/05/11 19:27, Minko escribió: >>>> Cool! >>>> I can use these locator rules also for the multiple language expressions in the 'default_name': >>>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html >>>> >>>> Example: >>>> leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] >>>> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] >>>> leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] >>>> leisure=pitch& sport=soccer [0x19 resolution 23] >>> I tried rules of type below, but it doesn't work for Morocco. >>> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 >>> road_class=3 road_speed=5 resolution 16] >>> highway=primary [0x03 road_class=3 road_speed=5 resolution 18] >>> >>> MapSouce shows "Morocco (MOR)" in the countries list, although >>> LocatorConfig.xml has the rule below and there's no occurrence of "MOR" >>> in the OSM data. >>> <country name="Morocco" abr="MAR"> >>> <variant>MA</variant> >>> <variant>MAR</variant> >>> </country> >>> I know I could use MOR instead of MAR in my style but, shouldn't it be >>> consistent with the LocatorConfig? >> It seems as if the LocatorConfig you changed is not used by mkgmap. Do >> you use a downloaded mkgmap.jar? I am not sure where your changed >> LocatorConfig.xml must be placed so that mkgmap does not use the bundled >> LocatorConfig.xml. > I have not changed LocatorConfig.xml, I'm using the default one. I use a > self compiled jar. Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)" That's good because this question is answered :-)
The style can work only if the boundaries of Morocco are contained in the precompiled boundary tiles. I think my europe compilation may contain a small part of northern morocco. So you should do the following steps: 1. Check that the boundary multipolygon of Morocco is complete and valid 2. Precompile the boundary tiles 3. Compile your map again using the precompiled boundary tiles
Then the style rules should work. I had already compiled Morocco's boundary (extracted from Geofabrik morocco.osm.pbf). What I didn't is converting bnd to gpx and checking it, but that will be tomorrow... I checked part of the bound tiles and they are correct. Here are all my steps, so you can see if I'm doing something wrong: 1-Extract boundaries: osmosis \ --read-pbf file=morocco.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=morocco-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
2-Map compilation: time /usr/lib/jvm/java-6-sun/bin/java -Xmx400m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=morocco-boundaries.osm.pbf --boundsdirectory=bounds_morocco --generate-sea=extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --description="OpenStreetMap-Morocco" --gmapsupp --country-name=MOROCCO --country-abbr=MAR --family-name="Open Street Map" --family-id=17 --product-id=1 --series-name="OSM-Morocco" --area-name="Morocco" --overview-mapname=55170000 --mapname=55170000 --name-tag-list=int_name,name --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --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 typ/MOROC-17.TYP morocco.osm.pbf I've seen streets/roads don't have city, region, country information assigned in my Morocco's map when searched in MapSource. As there's no city boundary and nearly no region boundary in OSM data mkgmap:region!=* and mkgmap:city!=* rules in style fail to fill that info and this seems to block country info to be assigned even if it is present. I have tuned style to assign a default city and region when missing and then country is correctly set (and also region if present), but even so, rule "highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16]" is not applied.
Carlos, I have not forgotten your described problem. 1. Country specific rules are not applied I cannot reproduce that. I have stripped down a style to use only the line file with the following content: mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country=DEU & highway=* [0x06 road_class=0 road_speed=2 resolution 22] So all highways (no matter which type) in Germany should be contained in the map. I compiled two tiles which cover some parts of germany and some parts of the Netherlands. The resulting map contains only all highways in germany. So the country specific rule seems to work. 2. Country info only is not applied You are right. At the moment each POI must have the city/region/country or city/country information. Without that the country information cannot be applied. This is not a problem of the locator branch but more a general problem of how the index is created. Maybe Steve can explain what combinations should be possible (although they might not be implemented yet). Some work has to be done at this point. WanMil

El 27/05/11 19:26, WanMil escribió:
Am 21.05.2011 19:45, schrieb Carlos Dávila:
El 20/05/11 11:06, Carlos Dávila escribió:
El 20/05/11 00:07, Carlos Dávila escribió:
El 19/05/11 23:15, WanMil escribió:
El 19/05/11 22:12, WanMil escribió: >> El 19/05/11 21:29, WanMil escribió: >>>> El 16/05/11 19:27, Minko escribió: >>>>> Cool! >>>>> I can use these locator rules also for the multiple language expressions in the 'default_name': >>>>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html >>>>> >>>>> Example: >>>>> leisure=pitch& sport=soccer& (mkgmap:country=NLD | mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23] >>>>> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19 default_name="Fussballfeld" resolution 23] >>>>> leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région Wallone") [0x19 default_name="terrain de football" resolution 23] >>>>> leisure=pitch& sport=soccer [0x19 resolution 23] >>>> I tried rules of type below, but it doesn't work for Morocco. >>>> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 >>>> road_class=3 road_speed=5 resolution 16] >>>> highway=primary [0x03 road_class=3 road_speed=5 resolution 18] >>>> >>>> MapSouce shows "Morocco (MOR)" in the countries list, although >>>> LocatorConfig.xml has the rule below and there's no occurrence of "MOR" >>>> in the OSM data. >>>> <country name="Morocco" abr="MAR"> >>>> <variant>MA</variant> >>>> <variant>MAR</variant> >>>> </country> >>>> I know I could use MOR instead of MAR in my style but, shouldn't it be >>>> consistent with the LocatorConfig? >>> It seems as if the LocatorConfig you changed is not used by mkgmap. Do >>> you use a downloaded mkgmap.jar? I am not sure where your changed >>> LocatorConfig.xml must be placed so that mkgmap does not use the bundled >>> LocatorConfig.xml. >> I have not changed LocatorConfig.xml, I'm using the default one. I use a >> self compiled jar. > Oh, I am sorry. I mixed up some things. Well, I'm must also say I'm sorry, as checking my parameters I've seen MOR was coming from my --country-abbr:-[ , but changing it to the right "MAR" didn't make the style work, although MapSource now lists "Morocco (MAR)" That's good because this question is answered :-)
The style can work only if the boundaries of Morocco are contained in the precompiled boundary tiles. I think my europe compilation may contain a small part of northern morocco. So you should do the following steps: 1. Check that the boundary multipolygon of Morocco is complete and valid 2. Precompile the boundary tiles 3. Compile your map again using the precompiled boundary tiles
Then the style rules should work. I had already compiled Morocco's boundary (extracted from Geofabrik morocco.osm.pbf). What I didn't is converting bnd to gpx and checking it, but that will be tomorrow... I checked part of the bound tiles and they are correct. Here are all my steps, so you can see if I'm doing something wrong: 1-Extract boundaries: osmosis \ --read-pbf file=morocco.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=morocco-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
2-Map compilation: time /usr/lib/jvm/java-6-sun/bin/java -Xmx400m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=morocco-boundaries.osm.pbf --boundsdirectory=bounds_morocco --generate-sea=extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --description="OpenStreetMap-Morocco" --gmapsupp --country-name=MOROCCO --country-abbr=MAR --family-name="Open Street Map" --family-id=17 --product-id=1 --series-name="OSM-Morocco" --area-name="Morocco" --overview-mapname=55170000 --mapname=55170000 --name-tag-list=int_name,name --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --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 typ/MOROC-17.TYP morocco.osm.pbf I've seen streets/roads don't have city, region, country information assigned in my Morocco's map when searched in MapSource. As there's no city boundary and nearly no region boundary in OSM data mkgmap:region!=* and mkgmap:city!=* rules in style fail to fill that info and this seems to block country info to be assigned even if it is present. I have tuned style to assign a default city and region when missing and then country is correctly set (and also region if present), but even so, rule "highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03 road_class=3 road_speed=5 resolution 16]" is not applied.
Carlos,
I have not forgotten your described problem.
1. Country specific rules are not applied I cannot reproduce that. I have stripped down a style to use only the line file with the following content: mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country=DEU& highway=* [0x06 road_class=0 road_speed=2 resolution 22]
So all highways (no matter which type) in Germany should be contained in the map.
I compiled two tiles which cover some parts of germany and some parts of the Netherlands. The resulting map contains only all highways in germany. So the country specific rule seems to work. I have followed your approach, but still can't get it working for Morocco. In order to get it working for Spain, I had to manually create an osm file with admin_level 2 relation (1311641) and merge it with the Europe's extract from geofabrik, as part of the boundaries seem to be missing in it, and then re-create the boundaries files. I did the same for Morocco (africa+mocorro) but it didn't work. I also tried changing name tag in morocco's admin_level 2 relation from the Arabic name to Morocco (I seem to recall name-tag-list doesn't work for relations) with no success, so now I don't know what else to try. My commands: osmosis --rb africa.osm.pbf --rx boundary_morocco.osm --merge --wb africa-morocco.osm.pbf omitmetadata=true
osmosis --read-pbf file=africa-morocco.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=africa-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12 java -Xmx400m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=africa-boundaries.osm.pbf --boundsdirectory=bounds_africa --generate-sea=extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --description="OpenStreetMap-Morocco" --family-name="Open Street Map" --family-id=17 --product-id=1 --series-name="OSM-Morocco" --area-name="Morocco" --overview-mapname=55170000 --mapname=55170000 --name-tag-list=int_name,name --index --ignore-maxspeeds --remove-short-arcs --merge-lines --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=rules typ/MOROC-17.TYP morocco.osm.pbf My "rules" style lines file for the test: mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country=MAR & highway=* [0x03 road_class=3 road_speed=5 resolution 16] mkgmap:country=ESP & highway=* [0x02 road_class=3 road_speed=5 resolution 18] After compiling the map only shows highways in the two Spanish cities in the North of Morocco.
2. Country info only is not applied You are right. At the moment each POI must have the city/region/country or city/country information. Without that the country information cannot be applied. This is not a problem of the locator branch but more a general problem of how the index is created. Maybe Steve can explain what combinations should be possible (although they might not be implemented yet). Some work has to be done at this point.

Carlos,
I have not forgotten your described problem.
1. Country specific rules are not applied I cannot reproduce that. I have stripped down a style to use only the line file with the following content: mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country=DEU& highway=* [0x06 road_class=0 road_speed=2 resolution 22]
So all highways (no matter which type) in Germany should be contained in the map.
I compiled two tiles which cover some parts of germany and some parts of the Netherlands. The resulting map contains only all highways in germany. So the country specific rule seems to work. I have followed your approach, but still can't get it working for Morocco. In order to get it working for Spain, I had to manually create an osm file with admin_level 2 relation (1311641) and merge it with the Europe's extract from geofabrik, as part of the boundaries seem to be missing in it, and then re-create the boundaries files. I did the same for Morocco (africa+mocorro) but it didn't work. I also tried changing name tag in morocco's admin_level 2 relation from the Arabic name to Morocco (I seem to recall name-tag-list doesn't work for relations) with no success, so now I don't know what else to try. My commands: osmosis --rb africa.osm.pbf --rx boundary_morocco.osm --merge --wb africa-morocco.osm.pbf omitmetadata=true
osmosis --read-pbf file=africa-morocco.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=africa-boundaries.osm.pbf omitmetadata=true compress=deflate inPipe.0=12
java -Xmx400m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=africa-boundaries.osm.pbf --boundsdirectory=bounds_africa --generate-sea=extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --description="OpenStreetMap-Morocco" --family-name="Open Street Map" --family-id=17 --product-id=1 --series-name="OSM-Morocco" --area-name="Morocco" --overview-mapname=55170000 --mapname=55170000 --name-tag-list=int_name,name --index --ignore-maxspeeds --remove-short-arcs --merge-lines --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=rules typ/MOROC-17.TYP morocco.osm.pbf
My "rules" style lines file for the test: mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:country=MAR& highway=* [0x03 road_class=3 road_speed=5 resolution 16] mkgmap:country=ESP& highway=* [0x02 road_class=3 road_speed=5 resolution 18]
After compiling the map only shows highways in the two Spanish cities in the North of Morocco.
Carlos, I couldn't reproduce your problem as you described it. I downloaded the Geofabrics africa dump from Jun 1st, precompiled the bounds files and then compiled the 4 tiles that covers morocco using your parameters. After that I got roads on the spain islands like teneriffe and morocco. So now you might have to check what's wrong with your map compilation process. As you stated the name-tag-list is important. The locator algorithm uses this list to get the name that is searched in the LocatorConfig.xml. This is also working for relations. I propose that you first remove the merging things. I cannot look into what's happening there. WanMil

On Wed, May 04, 2011 at 07:02:41PM +0200, WanMil wrote:
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it.
So please post your country specific rules as an answer in this thread.
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative lists rules for many countries. Finland does not have that many boundaries defined, but the few should follow the rules in the wiki. Marko

Possibly not what you have in mind, but how about an automatic "drive-on-left" for UK/Ireland/Japan/Australia/NZ/etc? On 04/05/2011 19:02, WanMil wrote:
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it.
So please post your country specific rules as an answer in this thread.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

This will not be fixed in the locator branch. But maybe someone else implement such rules in the style processor. WanMil
Possibly not what you have in mind, but how about an automatic "drive-on-left" for UK/Ireland/Japan/Australia/NZ/etc?
On 04/05/2011 19:02, WanMil wrote:
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it.
So please post your country specific rules as an answer in this thread.
WanMil

Am 04.05.2011 19:02, schrieb WanMil:
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it.
So please post your country specific rules as an answer in this thread.
WanMil I took these out of wiki-definition of admin_level:
#address-search mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:country="AUT" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="BEL" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="CZE" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="CZE" & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country="DNK" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="DNK" & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country="FIN" & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country="FIN" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="FRA" & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country="FRA" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="DEU" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="DEU" & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country="ISL" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="ITA" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="LUX" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="NLD" & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:country="NOR" & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country="POL" & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:country="POL" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="PRT" & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country="PRT" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="SVN" & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } mkgmap:country="ESP" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country="SWE" & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country="SWE" & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:country="CHE" & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }

This is what I'm using for Spain: 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_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=* & mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' } mkgmap:city!=* & openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } 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}' }

Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB works best for the Garmin index. What you'll then see is that some OSM boundaries need to be improved. But getting that done will create a perfectly working index (except for adresses, but it's always nice to have some wishes for the future :-) ) Cheers, Johan On Wed, 04 May 2011 23:48:34 +0200, Carlos Dávila <cdavilam@orangecorreo.es> wrote:
This is what I'm using for Spain: 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_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:region!=* & mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' } mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=* & openGeoDB:name=* { set mkgmap:city='${openGeoDB:name}' } 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-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

El 05/05/11 00:50, navmaps escribió:
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB works best for the Garmin index. What you'll then see is that some OSM boundaries need to be improved. But getting that done will create a perfectly working index (except for adresses, but it's always nice to have some wishes for the future :-) ) Thank you for the information, I'll try your suggestion. Last week I spent quite a lot of time improving boundaries, so I hope I can currently get good results.

Question to all: Should I remove the is_in:* and openGeoDB:* usage from the locator styles? Or should I give them lowest priority (use them only if no other rule matches)? What do you think? WanMil
El 05/05/11 00:50, navmaps escribió:
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB works best for the Garmin index. What you'll then see is that some OSM boundaries need to be improved. But getting that done will create a perfectly working index (except for adresses, but it's always nice to have some wishes for the future :-) ) Thank you for the information, I'll try your suggestion. Last week I spent quite a lot of time improving boundaries, so I hope I can currently get good results.

El 06/05/11 18:02, WanMil escribió:
Question to all:
Should I remove the is_in:* and openGeoDB:* usage from the locator styles? Or should I give them lowest priority (use them only if no other rule matches)?
What do you think? There are countries where boundary polygons/relations are completely missing. In such cases keeping is_in and openGeoDB may be useful. On the other side, if they are removed will encourage people to add such information to OSM. I think we have faced similar situations other times in the past.

I'm a proponent of skipping is_in and openGeoDB completely: 1. that shifts the attention in the right way: to improve faulty boundaries. 2. I noticed that using is_in and openGeoDB caused a multiple country selection in my Garmin for the same country; (on my Garmin) it's technically better for the index to only use boundaries 3. It might save development time (questions about missing streets in cities with faulty boundaries) On Fri, 06 May 2011 18:46:56 +0200, Carlos Dávila <cdavilam@orangecorreo.es> wrote:
El 06/05/11 18:02, WanMil escribió:
Question to all:
Should I remove the is_in:* and openGeoDB:* usage from the locator styles? Or should I give them lowest priority (use them only if no other rule matches)?
What do you think? There are countries where boundary polygons/relations are completely missing. In such cases keeping is_in and openGeoDB may be useful. On the other side, if they are removed will encourage people to add such information to OSM. I think we have faced similar situations other times in the past.
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

El 06/05/11 17:41, Carlos Dávila escribió:
El 05/05/11 00:50, navmaps escribió:
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB works best for the Garmin index. What you'll then see is that some OSM boundaries need to be improved. But getting that done will create a perfectly working index (except for adresses, but it's always nice to have some wishes for the future :-) ) Thank you for the information, I'll try your suggestion. Last week I spent quite a lot of time improving boundaries, so I hope I can currently get good results. You were right, with the rules below I get rid of most wrong State/Province in search dialog. I would keep is_in:city and addr:city because there may be more than one city/village/hamlet within an admin_level=8 boundary (municipalities) and they may help get the right place.
mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' } 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!=* & 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}' }

Hi Carlos, I know this problem, because I live in a city where exactly that is the case. The solution for that as has been applied in the Netherlands and Belgium is to use a lower level boundary: in Belgium admin_level 9 is used as the primary boundary, in the Netherlands admin_level 10 is used as primary boundary (both before admin_level 8 is used in the style files). Cheers, Johan On Sat, 07 May 2011 23:25:03 +0200, Carlos Dávila <cdavilam@orangecorreo.es> wrote:
El 06/05/11 17:41, Carlos Dávila escribió:
El 05/05/11 00:50, navmaps escribió:
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB works best for the Garmin index. What you'll then see is that some OSM boundaries need to be improved. But getting that done will create a perfectly working index (except for adresses, but it's always nice to have some wishes for the future :-) ) Thank you for the information, I'll try your suggestion. Last week I spent quite a lot of time improving boundaries, so I hope I can currently get good results. You were right, with the rules below I get rid of most wrong State/Province in search dialog. I would keep is_in:city and addr:city because there may be more than one city/village/hamlet within an admin_level=8 boundary (municipalities) and they may help get the right place.
mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
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!=* & 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-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

El 08/05/11 01:43, navmaps escribió:
Hi Carlos, I know this problem, because I live in a city where exactly that is the case. The solution for that as has been applied in the Netherlands and Belgium is to use a lower level boundary: in Belgium admin_level 9 is used as the primary boundary, in the Netherlands admin_level 10 is used as primary boundary (both before admin_level 8 is used in the style files). I had already thought about it, but according to wiki [1] both 9 and 10 levels are below the needed one. It would be necessary a new level between 8 and 9 for that purpose. Perhaps a discussion on talk-es is to be taken. [1] http://wiki.openstreetmap.org/wiki/Key:admin_level#admin_level (spain) Cheers, Johan
On Sat, 07 May 2011 23:25:03 +0200, Carlos Dávila <cdavilam@orangecorreo.es> wrote:
El 06/05/11 17:41, Carlos Dávila escribió:
El 05/05/11 00:50, navmaps escribió:
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB works best for the Garmin index. What you'll then see is that some OSM boundaries need to be improved. But getting that done will create a perfectly working index (except for adresses, but it's always nice to have some wishes for the future :-) )
Thank you for the information, I'll try your suggestion. Last week I spent quite a lot of time improving boundaries, so I hope I can currently get good results. You were right, with the rules below I get rid of most wrong State/Province in search dialog. I would keep is_in:city and addr:city because there may be more than one city/village/hamlet within an admin_level=8 boundary (municipalities) and they may help get the right place.
mkgmap:country!=*& mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
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!=*& 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-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.

Hello, short question, because somebody wrote it also in the openstreetmap-forum. In the default style seems to be an error. mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postalcode}' } should be mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postcode ='${mkgmap:postalcode}' } Cheers Martin Am 04.05.2011 um 19:02 schrieb WanMil:
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it.
So please post your country specific rules as an answer in this thread.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

El 07/05/11 18:28, Martin escribió:
Hello,
short question, because somebody wrote it also in the openstreetmap-forum. In the default style seems to be an error. mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postalcode}' } should be mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postcode ='${mkgmap:postalcode}' } Wouldn't it be the right one? mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' }
participants (8)
-
Carlos Dávila
-
Colin Smale
-
Henning Scholland
-
Marko Mäkelä
-
Martin
-
Minko
-
navmaps
-
WanMil