logo separator

[mkgmap-dev] Problem with bounds_*.zip

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Apr 22 07:05:06 BST 2013

Hi Felix,

okay, I will try to change the evaluation of options. 
This part of the program source is quite old (r801), but it contains some explicit comments like this
     * We may have to filter some options that we don't ever want to
     * set on the command line.
and this option is "levels".

So, I assume that Steve had a good reason to treat the levels option special,
but I don't understand yet what problem he saw...

Gerd

> Date: Sun, 21 Apr 2013 10:48:20 +0200
> From: extremecarver at gmail.com
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Problem with bounds_*.zip
> 
> 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
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130422/3e8e4161/attachment-0001.html 


More information about the mkgmap-dev mailing list