Hi Steve,
If there are multiple rules with the first term natural=mud then they are put into a list in the order that they occur in the file. They are then evaluated in order until one matches. Only the conditions after natural=mud are run, eg for the rules:
natural=mud & colour=brown [0x50 ...] natural=mud [0x51 ...]
you create a list of instructions that does the following: if colour == brown then return [0x50, ...] return [0x51, ...]
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.
3. Why doesn't RuleFileReader.optimiseAndSaveBinaryOp() check for second.isType(EXISTS)? Why doesn't it attempt to swap operands when first.isType(NOT_EXISTS)? No particular reason other than I am never tempted to start a rule with !=.
So yes you could rewrite (eg): a!=b & c=* as c=* & a!=b that would be valid.
OK, I will fix that in the parser, because it makes the language cleaner in my eyes (regular, symmetric, orthogonal, for want of a better word). The same would apply to second.isType(OR), I suppose. One last question. The attached patch does not affect runtime much (similar amount of difference in execution time can be observed between repeated runs), but it affects the map generation: -rw-r--r-- 1 marko marko 45474816 18.1. 09:00 gmapsupp.img -rw-r--r-- 1 marko marko 45475840 16.1. 22:17 gmapsupp-nop.img -rw-r--r-- 1 marko marko 45475840 18.1. 09:13 gmapsupp.img The first gmapsupp.img was generated with the patch applied, the latter two without. As far as I understood your explanation, these would be executed the same, under the highway=* key. (This would not change even if I added the above-mentioned tweakings for second.isType(), because the first.isType(EXISTS) would be checked before second.isType() in any case.) Do you have any idea why the surface ~ '...\|...' would omit some definitions that are included by the surface=... | surface=...? Best regards, Marko