Hi Steve,
I see. I guess that only the first matching [] rule will be run and that any {set} or {add} rules will not affect further tests.
There is a 'continue' keyword that allows further matches to take place.
The 'continue' keyword is for the [] action, right? And the further matches could be terminated by another [] action that would generate another map element, right?
The set and add actions are expected to affect further matches (as in people expect it to happen, as it is meant to work as-if the rules were applied in order), but as you will realise this is difficult to implement as you have to throw away optimisation if you detect that it could happen.
The style branch implements that a bit better.
I did not realise that the style branch has not been merged to trunk yet. Are you planning to do that soon? In which way does the implementation in the style branch differ from trunk?
The same would apply to second.isType(OR), I suppose.
What kind of rule would that work for?
The same type of rules as the first.isType(OR), but with the roles of first and second swapped. I am pulling the example from the source code comment. This is a bad example, because to my understanding, it would not be handled by the isType(OR) but the earlier isType(EXISTS): // (a=b|a=c) & d=f => (a=b&d=f) | (a=c&d=f) => solved The symmetric case would be // d=f & (a=b|a=c) which would now be translated into the same. (Would it be beneficial to check for isType(OR) within isType(AND) before the isType(EQUALS) and isType(EXISTS)?)
The backslashes should not be there. Running the following works fine with all backslashes removed (in RuleFileReaderTest).
You are right, I get the same size gmapsupp.img after removing the \ before |(). Uh oh, It seems that there must be a bug in the default style then. The regexps for smoothness and sac_scale are wrong. But I thought that I successfully tested the patch (setting mkgmap:unpaved=1) with a road whose smoothness was tagged bad. Marko