[mkgmap-dev] Style include files

Wed Sep 5 15:56:35 BST 2012

Hi,
I think if include is used by developers, you wont need include 
sections, because they will split their style-files into several parts. 
Eg. one part for address search, one part for routing one part for 
highways another part for non routable lines and so on.

Include a part is only useful, if you include the hole part and also in 
this case you'll have to be carefull with incompatible usage of Garmin-ID's.

Henning

Am 05.09.2012 16:27, schrieb Felix Hartmann:
> I "would need" or think it's easiest if there would be two things:
>
> a) include_section_XYZ from file_XYZ
> and b) include_file_XYZ
>
> So you could decide to either include a file containing several sections
> (so you can have section XY1 section XY2 and so on, for one layout, and
> section XX1 XX2 for another layout)
> or
> include the full content from a file.
>
> In any case, I think naming the relative path of the file should be
> best. Copying in stuff directly from the mkgmap.jar inbuilt styles,
> might cause too much errors. You could still copy in stuff from mkgmap
> inbuilt style, by pointing the file pointer to an mkgmap svn repository
> directory.
> --style-file and --style do cause confusion to many people I think.
> On 05.09.2012 16:06, Steve Ratcliffe wrote:
>> Hi
>>
>>> Last year, I wanted to divide the default style into modules. It would
>>> be easier to continue this with the style-include branch. Perhaps there
>>> could be a 'standard library' of files that all styles (including
>>> user-defined styles) could include?
>> A library is a good idea.
>>
>> I don't think that including from other styles is a bad idea,
>> the question is just how do we do it.
>>
>> If you are developing your own style then you can divide it
>> up into as many different files that you like and place them
>> all somewhere inside the style.
>>
>> You might want to include a file from one of the built in styles but
>> then you would be relying on it not changing too much in an
>> incompatible way.  Having a library of style fragments as a built in
>> style might go a long way to make that more manageable.
>>
>> So I'll ask another question: if there was a syntax
>>
>>     include some-file from some-style
>>
>> should the some-style be restricted to a library or any built in
>> style?  I am worried that --style-file and --style arguments already
>> cause some confusion.
>>
>> ..Steve
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev