logo separator

[mkgmap-dev] if-then in style

From Gerd Petermann GPetermann_muenchen at hotmail.com on Mon Feb 27 10:51:58 GMT 2017

Hi all,

I try to make up my mind about what is needed and what is not.

1) I did not yet find a good reason to have an else clause, so I think we should start without implementing it

unless one can give a good example.


2) The banch now implements the syntax

if (EXPR) then
...
end
by adding the expression EXPR  to each of the rules between 'then' and 'end' . Nested if-then are allowed.
This might cause confusion in the following case:


if (highway=proposed)

  proposed=footway {delete highway}
  surface=asphalt {echotags "test" } [... ]
end
What should happen for a way with highway=proposed, proposed=footway, surface=asphalt ?

I'd expect that the 2nd rule with echotags is triggered, but it is not because after the interpretation of the if-then clause the rules look like this:

proposed=footway & highway=proposed {delete highway}

surface=asphalt & highway=proposed {echotags "test" } [... ]

and since the first rule deletes the highway tag the 2nd isn't triggered.


My suggested interpretation was like this:
highway=proposed {set mkgmap:if:1000=true}

proposed=footway & mkgmap:if:1000=true {delete highway}

surface=asphalt & mkgmap:if:1000=true {echotags "test" } [... ]


And I think that we should make sure that those generated special tags like mkgmap:if:1000 are not used directly by the style author .

Another option might be to disallow the modification of any tag which appears in EXPR.
No idea if that would be easier to implement but I fear that it would lead to very confusing error messages.

Comments?


ciao,

Gerd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170227/2ee99037/attachment.html>


More information about the mkgmap-dev mailing list