Splitting is a bit misleading - it's more a doubling. And here is an example where continue doesn't do the job or leads to a complex logic: tourism = alpine_hut & name = * & ele = * {name '${name} (${ele}) (Berghütte)'} [0x4803 resolution 23] tourism = alpine_hut & name = * {name '${name} (Berghütte)'} [0x4803 resolution 23] tourism = alpine_hut & ele = * {name 'Berghütte (${ele})'} [0x4803 resolution 23] tourism = alpine_hut {name 'Berghütte'} [0x4803 resolution 23] The criterion for a doubling could be: the node contains more than one POI BTW: I think we have to deal in the future with more and more complex tags. Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Idea-for-a-split-pois-option-tp5459785p545994... Sent from the Mkgmap Development mailing list archive at Nabble.com.

but: separating something like tourism=alpine_hut and amenity=restaurant into 2 pois would be great - why not with an option file that contains all the key=value pairs that should not occur together in one node. using continue in such a case makes the style really messy (and pretty unpredictable too) in my opinion. The fact that continue isn't the default seems to be supported by two reasons: If continue were the default, it would take longer to process all the rules. There are rules written for general situations (boundary=?) that are meant to fire only when more specific rules do not fire. So I wonder about a keyword (or a default, since efficiency seems secondary to getting the right answer) that is like continue, but consumes the tags that matched to make the rule fire. That way tags would be removed as they are matched, so that following more general rules don't fire (shop=food goes away, so shop=* doesn't match), but that multiple garmin objects are generated in your hut/restaurant combination entity. Would that avoid what you find to be messy/unpredictable?

"consuming" a key value pair could be done with delete already. but i have a couple of catch all lines at the end of my style: name, ele, fixme... those would always fire if the style is always processed to the last lines. example: node: tourism=alpine_hut amenity=restaurant name=some-name ele=1000 fixme=ele approx only i could consume tourism/amenity like that: tourism=alpine_hut { delete tourism } [0x1000 resolution 24 continue] amenity=restaurant { delete amenity} [0x1001 resolution 24 continue] in that case all the catch all lines will fire, so in this case i'd get 5 pois on top of each other maybe one could use an auxiliary tag, like this tourism=alpine_hut { delete tourism; set catch-all=no; } [0x1000 resolution 24 continue] and then name=* & catch-all!=no [0x1002 resolution 24] Am 06.02.2012 13:48, schrieb Torsten Leistikow:

Greg Troxel schrieb am 06.02.2012 13:36:

...

So I wonder about a keyword (or a default, since efficiency seems secondary to getting the right answer) that is like continue, but consumes the tags that matched to make the rule fire. That way tags would be removed as they are matched, so that following more general rules don't fire (shop=food goes away, so shop=* doesn't match), but that multiple garmin objects are generated in your hut/restaurant combination entity. You can use the continue with_actions and just delete the shop tag in your example. For such tasks I use auxiliary tags like ignore_shop=yes, which I set when the first rule is processed. e.g. shop=food& ignore_shop!=yes {set ignore_shop=yes} [... continue with_actions] shop=*& ignore_shop!=yes {set ignore_shop=yes} [... continue with_actions]

So only the first matching shop rule will be processed, but all additional rules will be processed also.

Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

michael lohr schrieb am 06.02.2012 14:12:

maybe one could use an auxiliary tag, like this

tourism=alpine_hut { delete tourism; set catch-all=no; } [0x1000 resolution 24 continue]

and then

name=* & catch-all!=no [0x1002 resolution 24]

That's the way my style handles such problems. But be ware: you mus use "continue with_actions" and not only "continue", because otherwise the action part of a rule is only executed for the POI created by this rule and not for the following POIs. Gruss Torsten