[mkgmap-dev] style file reader error

Mon Jul 31 14:37:25 BST 2017

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 at parabola.me.uk] 
Sent: 30 July 2017 12:45
To: mkgmap-dev at 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