Hi Dave, I fully agree with you. The if-then-else syntax seems to create more problems than it solves. So, what was your initial idea when you wrote that it would be great to have if-then in styles?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Dave Swarthout <daveswarth...@gmail.com> Gesendet: Donnerstag, 16. März 2017 10:19:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] if-then-else in style and style options 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<mailto: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<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <po...@poczta.onet.pl<mailto:po...@poczta.onet.pl>> Gesendet: Freitag, 10. März 2017 20:14:49 An: mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto: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<mailto: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
