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

Sat Mar 18 07:37:13 GMT 2017

Hi Andrzej,

your approach looks better but requires a lot more changes in sources which I only understand partly
and which seem to be overly complex, probably because new features were added over the years.
Some examples:
I don't yet understand why we have classes ExpressionRule and ActionRule.
I don't understand why RuleSet implements Rule. In my eyes a collections of rules is different to a single rule.
I don't like the way how the <finalize> rules are implemented now.
I don't understand why StyleTester implements its own RuleFileReader (which currently doesn't understand if-then-else)

So, in short: I'd rather keep the current implementation and maybe start a new branch to rewrite the code in package osmstyle.

BTW: A different approach would be to extent the format of the overlays file so that one can specify
resolutions for the different overlaying lines, but I never liked the idea of the overlays file in the first place.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen at hotmail.com>
Gesendet: Freitag, 17. März 2017 15:51:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Andrzej,

okay, you are right, that sounds better than my approach. I'll try to code it that way.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej at poczta.onet.pl>
Gesendet: Freitag, 17. März 2017 14:02:55
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

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.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev