[mkgmap-dev] Problem with bounds_*.zip

Sun Apr 21 09:48:20 BST 2013

Hi Gerd,

I would say yes. So far everything based on order in the commandline 
caused only confusion.
Essentially for me it doesn't matter how it works, because I will know 
how to implement it, but I think in generell commandline is considered 
to override defaults - and therefore also style-file (for many people 
who don't even adapt the style-file, the style-file is some sort of 
default).
On 21.04.2013 10:44, GerdP wrote:
> Hi Felix,
>
> yes, but what about the order?
> Should
> --levels=0:24 1:22 --style-file=xyz
> give the same result as
>   --style-file=xyz --levels=0:24 1:22
> when xyz/options contains
> levels=0:24 1:20 2:16
>
> Gerd
>
>
> Felix Hartmann-2 wrote
>> I would prefer if command lines overrides the options file. No more, no
>> less.
>>
>> On 21.04.2013 10:27, GerdP wrote:
>>> Hi,
>>>
>>> got no answer on this. Now I meet the same problem again with the levels
>>> option.
>>> I don't fully understand the meaning of the levels statement as it is
>>> implemented now.
>>>
>>> If I got this right, the style files are always using either the value
>>> given
>>> in the options file or
>>> the value that is hard coded in LevelInfo.DEFAULT_LEVELS : "0:24, 1:22,
>>> 2:20, 3:18, 4:16"
>>> All rules will only use these values and NOT a value given on the command
>>> line.
>>>
>>> The command line levels option is used when the map is created. If the
>>> value
>>> is not given, the
>>> value used by the style is used here as well.
>>>
>>> So, what is the intended result if one uses levels on the command line?
>>> Should it work in combination with style rules that specify levels
>>> instead
>>> of resolutions?
>>>
>>> Ciao,
>>> Gerd
>>>
>>>
>>>
>>>
>>> GerdP wrote
>>>> Henning Scholland wrote
>>>>> Am 10.04.2013 09:06, schrieb Minko:
>>>>>> Hi Wanmil,
>>>>>>
>>>>>> I like your first option:
>>>>>> 1. Merge the options of the style file at the very beginning of mkgmap
>>>>>>     so that all mkgmap sources can uses the same set of options.
>>>>>>
>>>>>> A lot of options are related to the style files. When I distribute my
>>>>>> styles,
>>>>>> people (like Lambertus who 'produces' my Openfietsmap Worldwide)
>>>>>> don't have to change their mkgmap args file. The less options in this
>>>>>> args file the better.
>>>>> +1
>>>>>
>>>>> This is more easy. Also if you are generating different maps, which
>>>>> need
>>>>> different arguments.
>>>> I wonder what should happen when one uses something like this:
>>>> java -jar mkgmap.jar --style-file=s1 -c map1.conf --name-tag-list="..."
>>>> path1/*.o5m   --style-file=s2 -c map2.conf path2/*.o5m
>>>>
>>>> Should the --name-tag-list-parm override both style-files? I'd say no.
>>>> The wiki does not answer that.
>>>>
>>>> Gerd
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gis.19327.n5.nabble.com/Problem-with-bounds-zip-tp5753447p5757887.html
>>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>>
>> mkgmap-dev at .org
>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> -- 
>> keep on biking and discovering new trails
>>
>> Felix
>> openmtbmap.org & www.velomap.org
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at .org
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/Problem-with-bounds-zip-tp5753447p5757895.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org