Am Sonntag 27 November 2011, 15:34:31 schrieb Steve Ratcliffe:
> Hi
>
> >> indicates that they should be separated. They could be placed in one
> >> file, which would be used by each of the different geometry types.
> >
> > I agree, one file for these should be enough. I did not quite follow you
> > regarding access tags. They do not matter for polygons, do they? For
> > points, they can matter with link-pois-to-ways, which implements access
> > restrictions based on nearby nodes that carry access tags.
>
> I put them all together, because they all apply across a range of
> object types and modify the properties of the object rather than
> selecting what kind of object it is.
>
> >> Second, perhaps there is a need for two commands include-before and
> >> include-after which allow you to do the inclusion either way as
> >> appropriate for the situation.
> >
> > Could we have something similar to the #include and #undef in the C
> > preprocessor? For #undef (or whatever it will be called), an example
> > would be a style that is derived from the default style but removes the
> > lines rules for power=line and man_made=*.
>
> Removing rules would be tricky with the current implementation.
> Inclusion would be possible - do you mean randomly named files from
> the current style?
>
> ..Steve
IMO a #include statement that behaves like in C/C++ or even better like the
source statement within a shell script would be sufficient and much better
than the current base-style technique. The statement should be allowed at
any position within a stylefile and 'sources' the stated file line by line
exactly at that position. At the moment i archive this by generating the
styles with some cat commands before any mkgmap call.
Preventing double inclusion of a file is not so important for me, cause it may
or may not make sense including the same ruleset twice at different positions
within the 'final' ruleset.
Specifying the files to include platformindependent with relative and absolute
paths or relative to the 'default style' paths would be helpful. Examples:
source "../mystyletemplates/locatorrules.txt"
#include <default/locator.rules>
#def and #undef is IMO not so useful at all, cause you allways are able to
prevent the execution of a rule by catching the element within another rule
given before the rule you want to 'undef'.
Allowing an empty element type definition or a keyword 'next' or
'abort_element' comparable to the awk script 'next' statement would help much
more keeping the style files simple and readable. Example:
highway=residential & mynamespace:not_usable=yes [ next ]
or
highway=residential & mynamespace:not_usable=yes [ next ]
or
highway=residential & mynamespace:not_usable=yes {abort}
would prevent any further processing of the elements matching the condition.
If this is already implemented please let me know, did not see it within the
examples or the documentation.
Regards
Hasemann
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
