[mkgmap-dev] Commit: r1189: Remove the priority setting from the GType.

Mon Sep 14 22:35:19 BST 2009

Steve Ratcliffe wrote:
> Hi
>
> On 14/09/09 15:37, Torsten Leistikow wrote:
>   
>> Will your change also allow the generation of multiple garmin elements
>> from a single OSM element? I would guess so, since if we want to run
>> multiple actions than there shouldn't be anything against multiple
>> conversions.
>>     
>
> No it doesn't.  At least not at this stage.  I just want to get
> the stage where there are predictable results from the rules.
>
> I would like to know how people use the 'continue' patch.  It seems to
> me that there would be two cases.
>   
I use it extensively on my maps. The extended types made me even more 
dependent on the "continue" patch.

Basic things I always show on top:
bridges, tunnels, routes (mtb, bicycle, hiking, foot), mtb:scale, 
mtb:scale:uphill, sac_scale, ....

However also for cases like a way being tagged both highway=footway and 
highway=cycleway. or other rare things like boundaries, hedges, fences, 
etc...

Theese are too many combinations to be covered by working with extended 
styles.

So I am your group 1.

I would like to have the rules working a bit like the continue patch, so 
not only in order, but also that commands built upon each other. i.e. if 
three rules match the same street (e.g. changes to the name attribute) I 
would like all of them applied in order.
As an example take the following: highway=pedestrian, bicycle=no, 
ref=1234, name=anywhere

Now in my rules I would have the following (some other rules in between 
that don't match)

original name: "anywhere"
1. highway=* {name '${ref} ${name}' | '${ref}' | '${name}' }
resulting name: "1234 anywhere"
2. highway=pedestrian & {name '${name} pdstr' | 'pdstr' }
resulting name: "1234 anywhere pdstr"
3. highway=pedestrian & bicycle=no {name 'xbk ${name}' | 'xbk' }
resulting name "xbk 1234 anywhere pdstr"

In general I don't need any rule to take out the underlying street from 
further processing, but of course the finest would be to specify that 
rules with [continue] leave the underlying street open for further 
processing, while if no [continue] is given they are taken out.

So the following behaviour would be ideal I think:
original name: "anywhere"
1. highway=* {name '${ref} ${name}' | '${ref}' | '${name}' } [continue]
resulting name: "1234 anywhere"

2. highway=pedestrian & {name '${name} pdstr' | 'pdstr' }
resulting name: "1234 anywhere pdstr"

3. highway=pedestrian & bicycle=no {name 'xbk ${name}' | 'xbk' }
rule does not apply anymore, because 2. had no [continue] flag set, and 
thereby removed the whole line from further rule processing.

Another interesting idea would be to be able to make passes. so instead 
of putting [continue] one would put [run1], [run2], and so on. inside 
each "runX" all rules flagged are run in order. A match excludes it 
until the next higher run is passed. Then runX+1 run goes over takes the 
complete output of the runX. Finally to conclude any rule without [run] 
is run on everything in order.
> 1. Where the mapper has used the same way for two different things.
> A boundary that goes along a road is a common case.  In this case
> I imagine that you would always want to create both features (assuming
> that you are using them both) and for this to be detected automatically.
>
> 2. The styler wants to create two features to give some special effect.
> In those cases it seems right that it should have to be specified in
> the style somehow.  By using the 'continue' keyword or some other means.
> This may be less common now that extended types are implemented.
>
> ..Steve
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090914/61679b05/attachment.html 