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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev