[mkgmap-dev] Location not working in trunk default style

Sun Nov 27 23:45:30 GMT 2011

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 