logo separator

[mkgmap-dev] if-then in style

From Dave Swarthout daveswarthout at gmail.com on Mon Feb 27 11:04:33 GMT 2017

Hi Gert,

In your example you use proposed=footway. I've never seen any tagging like
that - what does it mean? Give us a better description of what you're
trying to accomplish in your test statement

if (highway=proposed)
  proposed=footway {delete highway}
  surface=asphalt {echotags "test" } [... ]
end


On Mon, Feb 27, 2017 at 5:51 PM, Gerd Petermann <
GPetermann_muenchen at hotmail.com> wrote:

> 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
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170227/feb60640/attachment.html>


More information about the mkgmap-dev mailing list