I don't like it but I don't know what to tell you to replace it with. All
such "tricks" make writing code less than straightforward and penalize the
casual user greatly. I am grateful to you and Ticker, et. al., for making
an effort to add this functionality but IMO if you resort to such
techniques it will be defeating the very purpose of creating the If-Then
construct, that purpose being to simplify the writing of these somewhat
strange style rules.
Respectfully,
Dave
On Thu, Mar 16, 2017 at 3:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Andrzej,
>
> well, my problem is the possible misinterpretation caused by ambiguity
> caused by the if-then interpretation,
> but I think I have found a possible solution.
>
> Let's look at some rules for boundaries in the default style:
> v1)
> boundary=administrative { name '${mkgmap:boundary_name}' }
> boundary=administrative & admin_level<3 [0x1e resolution 12]
> boundary=administrative & admin_level<5 [0x1d resolution 19]
> boundary=administrative & admin_level<7 [0x1c resolution 21]
> boundary=administrative & admin_level<9 [0x1c resolution 22]
> boundary=administrative [0x1c resolution 22]
>
> We said we want to be able to use if-then like this:
> v2)
> if (boundary=administrative ) then
> { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> [0x1c resolution 22]
> end
>
> With r3838 this did not work, because the each rule needs an expression.
> Ticker suggested to add a dummy expression like 1=1 so we would write
> v3)
> if (boundary=administrative ) then
> 1=1 { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> 1=1 [0x1c resolution 22]
> end
>
> but this is also not working as 1=1 is interpreted as $1='1' instead of
> "true"
>
> Now I noticed that the scanner allows to use () as an empty expression.
> So instead of v1 one already can write
> v4)
> if (boundary=administrative ) then
> () { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> () [0x1c resolution 22]
> end
>
> If we document this we no longer have a problem with the "one expression
> two objects" syntax like this:
> a=b [0xc ... resolution 24][0x10801 resolution 24]
> because we still say that a rule must start with an expression and mkgmap
> can automaticalyl
> add "continue" or "continue with_actions" for all but the last type
> defintion.
>
> If you don't like the () 'trick' I can again try to make a style function
> like true() work.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Andrzej Popowski <po...@poczta.onet.pl>
> Gesendet: Freitag, 10. März 2017 20:14:49
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> my idea was more simple, than your implementation. I just would like to
> create multiple map objects with single rule. I didn't put "continue"
> there, because I assumed, that all element type definition should be
> processed.
>
> Still "continue" could be applied, it would mean, that OSM object is
> processed further, possibly resulting in 3-rd map object or more. I
> think "continue" or "continue with_actions" could be added to last type
> definition.
>
> Any other more complicated rules, like adding actions after first type
> definition, could be written just like now, with multiple statements.
> While I appreciate more flexibility I'm afraid, it could clutter the style.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
