[mkgmap-dev] [locator] Europe boundary data for download

Tue May 3 16:46:14 BST 2011

Johan,

mkgmap:admin_level2, is_in:country and addr:country are all normalized 
to the three letter country code defined in the LocatorConfig.xml.

So you can tweek your rules for the Netherlands by adding the rule 
mkgmap:country="NLD":

mkgmap:country!=*&  mkgmap:admin_level2=* { set 
mkgmap:country='${mkgmap:admin_level2}' }

mkgmap:country="NLD" & mkgmap:region!=* & mkgmap:admin_level3=* { set
    mkgmap:region='${mkgmap:admin_level3}' }
etc.

WanMil

>   Hi WanMil
>
>   you did a very, very fine job on the locator and especially with this
>   version 1935. In my opinion it's only a short time now before the
>   locator branch is to be integrated into the core. Cities ánd streets
>   which I couldn't find using version 1930 can now be found in the Garmin
>   index.
>
>   One finetuning question: is it possible to differ the style settings
>   per country for multicountry maps (e.g. for the Netherlands admin_level
>   10 needs to be first in line, in Belgium and Luxembourg admin_level 8
>   needs to be first in line in order to prevent areas of a town to appear
>   as the complete city)
>
>   Cheers, Johan
>
>   By the way, i'm using..
>
>   mkgmap:country!=*&  mkgmap:admin_level2=* { set
>   mkgmap:country='${mkgmap:admin_level2}' }
>
>   mkgmap:region!=*&  mkgmap:admin_level3=* { set
>   mkgmap:region='${mkgmap:admin_level3}' }
>   mkgmap:region!=*&  mkgmap:admin_level4=* { set
>   mkgmap:region='${mkgmap:admin_level4}' }
>   mkgmap:region!=*&  mkgmap:admin_level5=* { set
>   mkgmap:region='${mkgmap:admin_level5}' }
>   mkgmap:region!=*&  mkgmap:admin_level6=* { set
>   mkgmap:region='${mkgmap:admin_level6}' }
>
>   mkgmap:city!=*&  mkgmap:admin_level10=* { set
>   mkgmap:city='${mkgmap:admin_level10}' }
>   mkgmap:city!=*&  mkgmap:admin_level8=* { set
>   mkgmap:city='${mkgmap:admin_level8}' }
>
>   mkgmap:postal_code!=*&  addr:postcode=* { set
>   mkgmap:postal_code='${addr:postcode}' }
>   mkgmap:postal_code!=*&  openGeoDB:postal_codes=* { set
>   mkgmap:postal_code='${openGeoDB:postal_codes}' }
>   mkgmap:postal_code!=*&  mkgmap:postcode=* { set
>   mkgmap:postal_code='${mkgmap:postalcode}' }
>
>   ..as my preferred settings now, because it produces the -in my opinion-
>   best index for multicountry maps
>
>   On Mon, 02 May 2011 22:33:58 +0200, WanMil<wmgcnfg at web.de>  wrote:
>>> The boundary-files have the same address
>>> (http://www.navmaps.eu/wanmil/europe_bounds_20110501.zip)?!
>>
>> Yes, they haven't changed because just the code to read them were
>> buggy.
>>
>>> And can you please provide logging.properties-file which I need to
>>> log
>>> the LocationHook. I've never done this before, I've tried it but I
>>> still
>>> get an empty logfile.
>>
>> Look into the wiki:
>> http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
>> You have to add the line
>> uk.me.parabola.mkgmap.reader.osm.LocationHook.level=FINE
>> to get all log messages from the LocationHook.
>>
>>>
>>> Some other questions:
>>> Do somebody know, what this error means:
>>> Ccode == null name=BELGI? - BELGIQUE - BELGIEN
>>
>> I have seen them too. The border of belgium is tagged with
>> boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE -
>> BELGIEN
>> The name is not contained in the LocatorConfig.xml so the Locator
>> does
>> not know the 3 letter ISO code for it.
>> The error message is not good but it was meant only for me for
>> debugging
>> purposes.
>>
>>>
>>> And mkgmap ask for some boundary files, which seems not to exist,
>>> but I
>>> downloaded the whole zip-file:
>>> SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz:
>>> Cannot
>>> load boundary file bounds/bounds_2550000_250000.bnd:
>>> java.io.FileNotFoundException: bounds/bounds_2550000_250000.bnd (No
>>> such
>>> file or directory)
>>> SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz:
>>> Cannot
>>> load boundary file bounds/bounds_2550000_300000.bnd:
>>> java.io.FileNotFoundException: bounds/bounds_2550000_300000.bnd (No
>>> such
>>> file or directory)
>>> SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz:
>>> Cannot
>>> load boundary file bounds/bounds_2600000_250000.bnd:
>>> java.io.FileNotFoundException: bounds/bounds_2600000_250000.bnd (No
>>> such
>>> file or directory)
>>> SCHWERWIEGEND (BoundaryUtil): ./tiles_germany/63240372.osm.gz:
>>> Cannot
>>> load boundary file bounds/bounds_2600000_300000.bnd:
>>> java.io.FileNotFoundException: bounds/bounds_2600000_300000.bnd (No
>>> such
>>> file or directory)
>>
>> I know that. I haven't checked that but possibly these boundary tiles
>> may contain no boundary at all (sea area?!?). I have to check that
>> later on.
>>
>> WanMil
>>
>>>
>>> Cheers
>>> Martin
>>>
>>> Am 02.05.2011 um 21:46 schrieb WanMil:
>>>
>>>>> On May 1, 2011, at 21:50, WanMil wrote:
>>>>>
>>>>>> I have also errors in a boundary file. Something seem to be wrong
>>>>>> with
>>>>>> the write or the reader. I am checking that...
>>>>>
>>>>> I just updated to SVN revision 1935: the malformed input error has
>>>>> not yet reappeared.
>>>>>
>>>>> You may have caught the error here.
>>>>>
>>>>> Cheers.
>>>>
>>>> Yes, you were quicker than me writing the email :-)
>>>> I found the bug. The Java stream for reading the data has two skip
>>>> methods (which is used to not read boundaries outside the tile
>>>> bounds).
>>>> One correct skip method and one incorrect. Now you can guess which
>>>> one I
>>>> used....
>>>>
>>>> So r1935 has fixed the bug. The compiled boundaries need not be
>>>> downloaded again. Additionally I committed the changes in the trunk
>>>> up
>>>> to r1932.
>>>>
>>>> WanMil
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev