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:[email protected]]
Sent: 30 July 2017 12:45
To: [email protected]
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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
