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.
>
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
