if-then-else in style and style options

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

if-then-else in style and style options

Gerd Petermann
Hi all,

I've applied the style-option_v3.patch to the branch, for details see  log message:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3827

I've also tried to fix the known problems with the interpretation of if then statements,
so I hope it works now:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&

Just to make this clear: The if statements are translated to "normal" rules, so you cannot do anything
with if-then which would not work without, you should also not (yet) exprect run time improvements.
The advantage is that you don't have to repeat phrases.

A complex sample that shows a possible usage.
# Roundabouts
if (junction=roundabout) then
        if (mkgmap:option:single-roundabout=true) then
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 18]
                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 19]
                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 20]
                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 21]
        else
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 24 continue]
                (highway=trunk | highway=trunk_link) [0x10801 resolution 18]
               
                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 24 continue]
                (highway=primary | highway=primary_link) [0x10802 resolution 19]
               
                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 24 continue]
                (highway=secondary | highway=secondary_link) [0x10803 resolution 20]
               
                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 24 continue]
                (highway=tertiary | highway=tertiary_link) [0x10804 resolution 21]
        end
        # minor roundabouts need no overlay
        (highway=unclassified | highway=minor ) [0x0c road_class=1 road_speed=1 resolution 21]
        highway=* [0x0c road_class=0 road_speed=1 resolution 22]
end
 
If the corresponding block in the default style lines file is replaced with these rules, you can
use option --style-option=single-roundabout to enable the rules which don't add 0x180x lines as overlays for roundabouts.

It might be possible to completely remove rules which would never be triggered but that is quite complex, so I leave that for later.

Gerd
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
Any feedback on this?

If nobody is interested in using if-then-else in style I'd be happy to use only the style-option_v3.patch
for trunk.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Gerd Petermann <[hidden email]>
Gesendet: Mittwoch, 1. März 2017 15:54:02
An: [hidden email]
Betreff: [mkgmap-dev] if-then-else  in style and style options

Hi all,

I've applied the style-option_v3.patch to the branch, for details see  log message:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3827

I've also tried to fix the known problems with the interpretation of if then statements,
so I hope it works now:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&

Just to make this clear: The if statements are translated to "normal" rules, so you cannot do anything
with if-then which would not work without, you should also not (yet) exprect run time improvements.
The advantage is that you don't have to repeat phrases.

A complex sample that shows a possible usage.
# Roundabouts
if (junction=roundabout) then
        if (mkgmap:option:single-roundabout=true) then
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 18]
                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 19]
                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 20]
                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 21]
        else
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 24 continue]
                (highway=trunk | highway=trunk_link) [0x10801 resolution 18]

                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 24 continue]
                (highway=primary | highway=primary_link) [0x10802 resolution 19]

                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 24 continue]
                (highway=secondary | highway=secondary_link) [0x10803 resolution 20]

                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 24 continue]
                (highway=tertiary | highway=tertiary_link) [0x10804 resolution 21]
        end
        # minor roundabouts need no overlay
        (highway=unclassified | highway=minor ) [0x0c road_class=1 road_speed=1 resolution 21]
        highway=* [0x0c road_class=0 road_speed=1 resolution 22]
end

If the corresponding block in the default style lines file is replaced with these rules, you can
use option --style-option=single-roundabout to enable the rules which don't add 0x180x lines as overlays for roundabouts.

It might be possible to completely remove rules which would never be triggered but that is quite complex, so I leave that for later.

Gerd
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

AlaskaDave
I'm sorry Gerd, I want to experiment with the new statements but I just don't have the time to play at the moment. Please commit the changes if you haven't already, and I'll get the new version and experiment when I can.

Dave

On Tue, Mar 7, 2017 at 9:09 PM, Gerd Petermann <[hidden email]> wrote:
Any feedback on this?

If nobody is interested in using if-then-else in style I'd be happy to use only the style-option_v3.patch
for trunk.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Gerd Petermann <[hidden email]>
Gesendet: Mittwoch, 1. März 2017 15:54:02
An: [hidden email]
Betreff: [mkgmap-dev] if-then-else  in style and style options

Hi all,

I've applied the style-option_v3.patch to the branch, for details see  log message:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3827

I've also tried to fix the known problems with the interpretation of if then statements,
so I hope it works now:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&

Just to make this clear: The if statements are translated to "normal" rules, so you cannot do anything
with if-then which would not work without, you should also not (yet) exprect run time improvements.
The advantage is that you don't have to repeat phrases.

A complex sample that shows a possible usage.
# Roundabouts
if (junction=roundabout) then
        if (mkgmap:option:single-roundabout=true) then
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 18]
                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 19]
                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 20]
                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 21]
        else
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 24 continue]
                (highway=trunk | highway=trunk_link) [0x10801 resolution 18]

                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 24 continue]
                (highway=primary | highway=primary_link) [0x10802 resolution 19]

                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 24 continue]
                (highway=secondary | highway=secondary_link) [0x10803 resolution 20]

                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 24 continue]
                (highway=tertiary | highway=tertiary_link) [0x10804 resolution 21]
        end
        # minor roundabouts need no overlay
        (highway=unclassified | highway=minor ) [0x0c road_class=1 road_speed=1 resolution 21]
        highway=* [0x0c road_class=0 road_speed=1 resolution 22]
end

If the corresponding block in the default style lines file is replaced with these rules, you can
use option --style-option=single-roundabout to enable the rules which don't add 0x180x lines as overlays for roundabouts.

It might be possible to completely remove rules which would never be triggered but that is quite complex, so I leave that for later.

Gerd
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
Hi Dave,

the coding is done unless one finds errors. Only documentation is missing.
I hoped to get some feedback that it really improves readabilty (as it cannot improve performance for now).

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Dave Swarthout <[hidden email]>
Gesendet: Dienstag, 7. März 2017 15:40:40
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

I'm sorry Gerd, I want to experiment with the new statements but I just don't have the time to play at the moment. Please commit the changes if you haven't already, and I'll get the new version and experiment when I can.

Dave

On Tue, Mar 7, 2017 at 9:09 PM, Gerd Petermann <[hidden email]<mailto:[hidden email]>> wrote:
Any feedback on this?

If nobody is interested in using if-then-else in style I'd be happy to use only the style-option_v3.patch
for trunk.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]<mailto:[hidden email]>> im Auftrag von Gerd Petermann <[hidden email]<mailto:[hidden email]>>
Gesendet: Mittwoch, 1. März 2017 15:54:02
An: [hidden email]<mailto:[hidden email]>
Betreff: [mkgmap-dev] if-then-else  in style and style options

Hi all,

I've applied the style-option_v3.patch to the branch, for details see  log message:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3827

I've also tried to fix the known problems with the interpretation of if then statements,
so I hope it works now:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&

Just to make this clear: The if statements are translated to "normal" rules, so you cannot do anything
with if-then which would not work without, you should also not (yet) exprect run time improvements.
The advantage is that you don't have to repeat phrases.

A complex sample that shows a possible usage.
# Roundabouts
if (junction=roundabout) then
        if (mkgmap:option:single-roundabout=true) then
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 18]
                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 19]
                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 20]
                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 21]
        else
                (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 24 continue]
                (highway=trunk | highway=trunk_link) [0x10801 resolution 18]

                (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 24 continue]
                (highway=primary | highway=primary_link) [0x10802 resolution 19]

                (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 24 continue]
                (highway=secondary | highway=secondary_link) [0x10803 resolution 20]

                (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 24 continue]
                (highway=tertiary | highway=tertiary_link) [0x10804 resolution 21]
        end
        # minor roundabouts need no overlay
        (highway=unclassified | highway=minor ) [0x0c road_class=1 road_speed=1 resolution 21]
        highway=* [0x0c road_class=0 road_speed=1 resolution 22]
end

If the corresponding block in the default style lines file is replaced with these rules, you can
use option --style-option=single-roundabout to enable the rules which don't add 0x180x lines as overlays for roundabouts.

It might be possible to completely remove rules which would never be triggered but that is quite complex, so I leave that for later.

Gerd
_______________________________________________
mkgmap-dev mailing list
[hidden email]<mailto:[hidden email]>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]<mailto:[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

popej
Hi Gerd,

I have run some tests with current code and spotted no problems. I have
tested both, if-then-else statement and style-option.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
Hi Andrzej,

thanks, so I'll try to document the new syntax next.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Dienstag, 7. März 2017 17:40:16
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Gerd,

I have run some tests with current code and spotted no problems. I have
tested both, if-then-else statement and style-option.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
Hi all,

while writing the documentation I noticed this possible problem case:
The lines file in the default style contains these rules:
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]

So, one may want to extract the clause boundary=administrative  like this:
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

The problem: It doesn't work because the lines
        { name '${mkgmap:boundary_name}' }
and
        [0x1c resolution 22]
are not a valid rules and the rule parser "forgets" that the boundary=administrative expression will be added.

What do you think? Should mkgmap support this syntax?

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Gerd Petermann <[hidden email]>
Gesendet: Dienstag, 7. März 2017 20:10:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Andrzej,

thanks, so I'll try to document the new syntax next.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Dienstag, 7. März 2017 17:40:16
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Gerd,

I have run some tests with current code and spotted no problems. I have
tested both, if-then-else statement and style-option.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Ticker Berkin
Hi

I think you should document that you need a dummy condition, ie

if (...) then
  1=1 {action}
  ...
  1=1 [0x1c ...]
end

(I assume this should work OK)

Ticker

On Wed, 2017-03-08 at 08:07 +0000, Gerd Petermann wrote:

> Hi all,
>
> while writing the documentation I noticed this possible problem case:
> The lines file in the default style contains these rules:
> 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]
>
> So, one may want to extract the clause boundary=administrative  like
> this:
> 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
>
> The problem: It doesn't work because the lines
>         { name '${mkgmap:boundary_name}' }
> and
>         [0x1c resolution 22]
> are not a valid rules and the rule parser "forgets" that the
> boundary=administrative expression will be added.
>
> What do you think? Should mkgmap support this syntax?
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Gerd Petermann <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 20:10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Andrzej,
>
> thanks, so I'll try to document the new syntax next.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Andrzej Popowski <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 17:40:16
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> I have run some tests with current code and spotted no problems. I
> have
> tested both, if-then-else statement and style-option.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
It would not work because 1=1 is interpreted as
$1='1'
and that will probably not be true.
Same effect with '1' = '1' .

Maybe we can add a style function "true()" which always retrurns true for this?

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Mittwoch, 8. März 2017 09:25:34
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi

I think you should document that you need a dummy condition, ie

if (...) then
  1=1 {action}
  ...
  1=1 [0x1c ...]
end

(I assume this should work OK)

Ticker

On Wed, 2017-03-08 at 08:07 +0000, Gerd Petermann wrote:

> Hi all,
>
> while writing the documentation I noticed this possible problem case:
> The lines file in the default style contains these rules:
> 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]
>
> So, one may want to extract the clause boundary=administrative  like
> this:
> 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
>
> The problem: It doesn't work because the lines
>         { name '${mkgmap:boundary_name}' }
> and
>         [0x1c resolution 22]
> are not a valid rules and the rule parser "forgets" that the
> boundary=administrative expression will be added.
>
> What do you think? Should mkgmap support this syntax?
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Gerd Petermann <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 20:10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Andrzej,
>
> thanks, so I'll try to document the new syntax next.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Andrzej Popowski <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 17:40:16
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> I have run some tests with current code and spotted no problems. I
> have
> tested both, if-then-else statement and style-option.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

AlaskaDave
This is probably coming too late but I was going to suggest earlier that the "end" directive be changed to "endif" to be more consistent with other programming languages. I've been away from programming for a long time - many languages (Java, C++, PHP) seem to use braces to end a control loop nowadays. No big deal either way.

Also, in your example, would an "Else" directive before the "[0x1c resolution 22]" the do the job? The program would still have to 'remember" that it was evaluating the "if " statement above, however.

Dave

On Wed, Mar 8, 2017 at 3:34 PM, Gerd Petermann <[hidden email]> wrote:
It would not work because 1=1 is interpreted as
$1='1'
and that will probably not be true.
Same effect with '1' = '1' .

Maybe we can add a style function "true()" which always retrurns true for this?

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Mittwoch, 8. März 2017 09:25:34
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi

I think you should document that you need a dummy condition, ie

if (...) then
  1=1 {action}
  ...
  1=1 [0x1c ...]
end

(I assume this should work OK)

Ticker

On Wed, 2017-03-08 at 08:07 +0000, Gerd Petermann wrote:
> Hi all,
>
> while writing the documentation I noticed this possible problem case:
> The lines file in the default style contains these rules:
> 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]
>
> So, one may want to extract the clause boundary=administrative  like
> this:
> 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
>
> The problem: It doesn't work because the lines
>         { name '${mkgmap:boundary_name}' }
> and
>         [0x1c resolution 22]
> are not a valid rules and the rule parser "forgets" that the
> boundary=administrative expression will be added.
>
> What do you think? Should mkgmap support this syntax?
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Gerd Petermann <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 20:10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Andrzej,
>
> thanks, so I'll try to document the new syntax next.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Andrzej Popowski <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 17:40:16
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> I have run some tests with current code and spotted no problems. I
> have
> tested both, if-then-else statement and style-option.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
Hi Dave,

I prefer end to endif, but it would be easy to change that. I don't get the idea with else.
The implemented logic is that fori
f (a=b) then ...if-rules... else ...elserules... end
the term (a=b) is added to the if-rules and !(a=b) is added to the else-rules.

It seems you think of something like a switch-case-default statement ?

Gerd



________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Dave Swarthout <[hidden email]>
Gesendet: Mittwoch, 8. März 2017 09:54:29
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

This is probably coming too late but I was going to suggest earlier that the "end" directive be changed to "endif" to be more consistent with other programming languages. I've been away from programming for a long time - many languages (Java, C++, PHP) seem to use braces to end a control loop nowadays. No big deal either way.

Also, in your example, would an "Else" directive before the "[0x1c resolution 22]" the do the job? The program would still have to 'remember" that it was evaluating the "if " statement above, however.

Dave

On Wed, Mar 8, 2017 at 3:34 PM, Gerd Petermann <[hidden email]<mailto:[hidden email]>> wrote:
It would not work because 1=1 is interpreted as
$1='1'
and that will probably not be true.
Same effect with '1' = '1' .

Maybe we can add a style function "true()" which always retrurns true for this?

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]<mailto:[hidden email]>> im Auftrag von Ticker Berkin <[hidden email]<mailto:[hidden email]>>
Gesendet: Mittwoch, 8. März 2017 09:25:34
An: [hidden email]<mailto:[hidden email]>
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi

I think you should document that you need a dummy condition, ie

if (...) then
  1=1 {action}
  ...
  1=1 [0x1c ...]
end

(I assume this should work OK)

Ticker

On Wed, 2017-03-08 at 08:07 +0000, Gerd Petermann wrote:

> Hi all,
>
> while writing the documentation I noticed this possible problem case:
> The lines file in the default style contains these rules:
> 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]
>
> So, one may want to extract the clause boundary=administrative  like
> this:
> 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
>
> The problem: It doesn't work because the lines
>         { name '${mkgmap:boundary_name}' }
> and
>         [0x1c resolution 22]
> are not a valid rules and the rule parser "forgets" that the
> boundary=administrative expression will be added.
>
> What do you think? Should mkgmap support this syntax?
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]<mailto:[hidden email]>> im Auftrag
> von Gerd Petermann <[hidden email]<mailto:[hidden email]>>
> Gesendet: Dienstag, 7. März 2017 20:10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Andrzej,
>
> thanks, so I'll try to document the new syntax next.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]<mailto:[hidden email]>> im Auftrag
> von Andrzej Popowski <[hidden email]<mailto:[hidden email]>>
> Gesendet: Dienstag, 7. März 2017 17:40:16
> An: [hidden email]<mailto:[hidden email]>
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> I have run some tests with current code and spotted no problems. I
> have
> tested both, if-then-else statement and style-option.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]<mailto:[hidden email]>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]<mailto:[hidden email]>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]<mailto:[hidden email]>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]<mailto:[hidden email]>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]<mailto:[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
In reply to this post by Ticker Berkin
Hi all,

I tried to implement some kind of dummy expression but failed.
If you think that mkgmap should allow syntax like
if (...) then
  {action}
end

I can make that work with the attached patch (which also contains a unit test)

I am not an expert for language or parser design, but it feels better to allow this
although I would only use it when the if really replaces repeated expressions.

Comments?
Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Mittwoch, 8. März 2017 09:25:34
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi

I think you should document that you need a dummy condition, ie

if (...) then
  1=1 {action}
  ...
  1=1 [0x1c ...]
end

(I assume this should work OK)

Ticker

On Wed, 2017-03-08 at 08:07 +0000, Gerd Petermann wrote:

> Hi all,
>
> while writing the documentation I noticed this possible problem case:
> The lines file in the default style contains these rules:
> 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]
>
> So, one may want to extract the clause boundary=administrative  like
> this:
> 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
>
> The problem: It doesn't work because the lines
>         { name '${mkgmap:boundary_name}' }
> and
>         [0x1c resolution 22]
> are not a valid rules and the rule parser "forgets" that the
> boundary=administrative expression will be added.
>
> What do you think? Should mkgmap support this syntax?
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Gerd Petermann <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 20:10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Andrzej,
>
> thanks, so I'll try to document the new syntax next.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Andrzej Popowski <[hidden email]>
> Gesendet: Dienstag, 7. März 2017 17:40:16
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> I have run some tests with current code and spotted no problems. I
> have
> tested both, if-then-else statement and style-option.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

if-then-no-expression-v1.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

popej
Hi Gerd,

I don't think that kind of expression is necessary, unless it speeds up
compilation, which it probably doesn't in current implementation. But it
would be nice to have it. Maybe using keyword "apply" would help?
Similarly like in relations.

Just another thought, could we get following syntax:
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24][0x10801 resolution 18]

instead of 2 rules:
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x10801
resolution 18]

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
Hi Andrzej,

okay, I think that meant I should apply the patch, done with r3839.

I've also checked your idea for the shorter form. I first thought it is simple but then noticed that
you didn't specify the continue statement in the shorter form.
I guess you want that to be added automatically. Does that also mean that "with_actions" should
be added automatically if there are actions?
In other words: If we have
a=b {name ... } [0x0C ... resolution 24] [0x10801 resolution 18]
would that be the same as
a=b {name ... } [0x0C ... resolution 24 continue with_actions]
a=b [0x10801 resolution 18]

I guess that also means we should allow
a=b {name ... } [0x0C ... resolution 24] {set ... } [0x10801 resolution 18]
as a replacement for
a=b {name ... } [0x0C ... resolution 24 continue with_actions]
a=b {set ... }  [0x10801 resolution 18]

Now, I think that mens we should also allow
a=b {name ... } [0x0C ... resolution 24] {set c=2 }
as a repelacement for
a=b {name ... } [0x0C ... resolution 24 continue with_actions]
a=b  {set c=2 }

The attached patch seems to implement it that way and contains some unit tests.
I hope it doesn't mess up error handling when the style contains syntax errors.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Donnerstag, 9. März 2017 14:57:11
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Gerd,

I don't think that kind of expression is necessary, unless it speeds up
compilation, which it probably doesn't in current implementation. But it
would be nice to have it. Maybe using keyword "apply" would help?
Similarly like in relations.

Just another thought, could we get following syntax:
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24][0x10801 resolution 18]

instead of 2 rules:
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x10801
resolution 18]

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

reuse-expression-v1.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
I just noticed that the patch reuse-expression-v1.patch and the latest change (r3839) can make problems:
if (a=b) then
  name(..)
  [0x01 ... resolution 18 continue]
end

is interpreted as
if (a=b) then
  {name ..}  [0x01 ... resolution 18 continue]
end
while the old form
a=b {name ..}
a=b [0x01 ... resolution 18 continue]
has a different meaning

So, I'll revert r3839 for now :-(

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Gerd Petermann <[hidden email]>
Gesendet: Freitag, 10. März 2017 09:10:40
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Andrzej,

okay, I think that meant I should apply the patch, done with r3839.

I've also checked your idea for the shorter form. I first thought it is simple but then noticed that
you didn't specify the continue statement in the shorter form.
I guess you want that to be added automatically. Does that also mean that "with_actions" should
be added automatically if there are actions?
In other words: If we have
a=b {name ... } [0x0C ... resolution 24] [0x10801 resolution 18]
would that be the same as
a=b {name ... } [0x0C ... resolution 24 continue with_actions]
a=b [0x10801 resolution 18]

I guess that also means we should allow
a=b {name ... } [0x0C ... resolution 24] {set ... } [0x10801 resolution 18]
as a replacement for
a=b {name ... } [0x0C ... resolution 24 continue with_actions]
a=b {set ... }  [0x10801 resolution 18]

Now, I think that mens we should also allow
a=b {name ... } [0x0C ... resolution 24] {set c=2 }
as a repelacement for
a=b {name ... } [0x0C ... resolution 24 continue with_actions]
a=b  {set c=2 }

The attached patch seems to implement it that way and contains some unit tests.
I hope it doesn't mess up error handling when the style contains syntax errors.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Donnerstag, 9. März 2017 14:57:11
An: [hidden email]
Betreff: Re: [mkgmap-dev] if-then-else in style and style options

Hi Gerd,

I don't think that kind of expression is necessary, unless it speeds up
compilation, which it probably doesn't in current implementation. But it
would be nice to have it. Maybe using keyword "apply" would help?
Similarly like in relations.

Just another thought, could we get following syntax:
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24][0x10801 resolution 18]

instead of 2 rules:
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x10801
resolution 18]

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

popej
In reply to this post by Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
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 <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Freitag, 10. März 2017 20:14:49
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

AlaskaDave
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 <[hidden email]> 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 <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Freitag, 10. März 2017 20:14:49
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

Gerd Petermann
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 <[hidden email]> im Auftrag von Dave Swarthout <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> im Auftrag von Andrzej Popowski <[hidden email]<mailto:[hidden email]>>
Gesendet: Freitag, 10. März 2017 20:14:49
An: [hidden email]<mailto:[hidden email]>
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
[hidden email]<mailto:[hidden email]>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]<mailto:[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if-then-else in style and style options

popej
Hi Gerd,

if-then-else is great. The last problem with admin boundaries doesn't
change it. We can apply the same the basic syntax for a rule, regardless
if inside or outside of if-then-else condition and simply accept, that
rules for boundaries can't be rewritten with if-then-else. They are
simple rules, so no much gain anyway.

For me the primary application for if-then-else would be with
style-option, like this:

if (mkgmap:option:...=true) then
   ...
else
   ...
end

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
12
Loading...