[mkgmap-dev] if-then-else in style and style options

Fri Mar 17 14:51:44 GMT 2017

Hi

I'd have thought the most common use of this feature is to have
different types for different resolutions/road attributes/etc ie:

junction=roundabout & (highway=trunk | highway=trunk_link)
   [0x10801 resolution 18 - 23 default_name "name1"]
   [0x0c road_class=4 road_speed=2 resolution 24 default_name "name2"]
   [0xXX...]

and the rule match simply generates multiple map objects from the same
input object, ie {action} if any, is evaluated once. The
meaning/placement of 'Continue [with-actions]' becomes a bit more
confusing and maybe should be forbidden on all but the last [].

Maybe, to remove the ambiguities that are creeping in when this is
combined with if-then-end and the match expression can disappear, there
should be a '&' between:

tag=val {action1; action2} [type1 res1] & [type2 res2] & [continue with
-actions]

My other thought is that this and if-then-end is just increasing the
complexity of the style rule interpretation for no benefit to the final
map, just to save the style author duplicating a few words of text.

Ticker

On Fri, 2017-03-17 at 14:02 +0100, Andrzej Popowski wrote:
> Hi Gerd,
> 
> you seem to evaluate scenarios, that I didn't think of. You probably 
> want to unwind a rule with double types into 2 rules with single
> type. 
> My idea was different, based on my guess, how mkgmap works. I have 
> looked at code now, and I can explain more precisely.
> 
> First there is class ActionRule, which contains a trio:
>   private Op expression;
>   private final List<Action> actions;
>   private final GType type;
> 
> Here I would suggest to add 4-th element:
>   private final GType type2;
> 
> And then support it in all methods, like add creator with 2 types:
> 
> public ActionRule(Op expression, List<Action> actions, GType type,
> GType 
> type2)
> 
> 
> Or support for 2 types in resolveType:
> 
> if (type != null && finalizeRule != null) {
> 	....
> 	if (type2 != null) {
> 		...
> 	}
> }
> 
> And similarly in RuleFileReader:
> 
> GType type = null;
> GType type2 = null;
> if (scanner.checkToken("[")) {
> 	type = typeReader.readType(...);
> 	if (scanner.checkToken("[") {
> 		type2 = typeReader.readType(...);
> 	}
> }
> else ...
> saveRule(scanner, expr, actionList, type, type2);
> 
> 
> I hope my theoretical implementation answers your questions. When 2
> type 
> elements are present, there is no need to evaluate "continue" or 
> "continue with_actions" in first element, it is hardcoded as
> "continue 
> with_actions". And "continue" in last element will result in further 
> processing of OSM object.
> 
> There is no limitation for content of action part, rule with 2 types 
> behaves exactly like a rule with single type.
> 
> I'm sure that my understanding of your code is incomplete but I hope
> the 
> general idea is feasible. I think type element could be even a list, 
> like actions.
> 