HI Steve, the patch fixes the problem I gave. However, I also found an allied problem that it doesn't fix (I had inadvertently posted this one just to Gerd rather than the list). Rewriting the rules to use the not operator and equals rather than not equals: name~'(?i)ferry terminal' & !(highway=bus_stop) {echotags 'Trigger 3'} - this works fine !(highway=bus_stop) & name~'(?i)ferry terminal' {echotags 'Trigger 4'} - this fails with an error "Invalid rule Expression" (without explaining what the error was) Is it possible to fix this one as well? Thanks, Mike -----Original Message----- From: Steve Ratcliffe [mailto:steve@parabola.me.uk] Sent: 30 July 2017 12:45 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] style file reader error Hi Mike
Hi, I seem to have found a bug in the style file reader - it does not appear to work correctly if the first term is a not equals term. For example, with the following two rules only the latter one correctly triggers:
highway!=bus_stop & name~'(?i)ferry terminal' {echotags 'Trigger 1'} name~'(?i)ferry terminal' & highway!=bus_stop {echotags 'Trigger 2'}
Yes that is a bug, thanks for reporting it.
I think it is failing to match when there is no highway tag at all. If you start with highway!=* as your first term in a rule, the style reader throws it out as not valid with "Cannot start rule with tag!=*" and I think this may be related.
The rules were more restrictive in the past, and when an error message doesn't make sense it is usually down to a bug, since these things should not happen any more. Although the code does require that an equals or exists terms is first, it is also supposed to re-arrange the expression so that is the case. So your first expression should have been re-written to name=* && name~'(?i)ferry terminal' & highway!=bus_stop There is a second bug, in that having failed to re-arrange it properly it should have then failed with an error. As it turns out there was a test for this, but it was saying that it should be allowed instead of being a failure. The only intended restriction now is that you cannot write a rule that would match an element without any tags at all. The attached patch should fix both these issues. ..Steve