Re: [mkgmap-dev] if-then-else in style and style options
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Parallel major roads to cycleways
There is a fledgling effort underway here in Chiang Mai to do a similar thing. This effort centers around the desirability of a route for bicycling. It deals with scenic vs dangerous roads for cycling and the 3 point system it uses might be insufficient for your needs but it might be adapted. Worth a look at any rate. https://wiki.openstreetmap.org/wiki/WikiProject_Thailand#Bicycling_tagging_.28currently_for_Chiang_Mai_only.29 Dave On Thu, Mar 16, 2017 at 5:06 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi, > > I just want to share an idea which might be interesting for cycling maps: > In Germany and probably also Austria) many major roads have a parallel > cycleway close to it, often only separated by a patch of grass or > natural=tree_row. > Example: A way with bicycle=designated : > http://www.openstreetmap.org/way/243499929 > runs next to highway=primary B213 > http://www.openstreetmap.org/way/328470949 > > I think nearly no cyclist likes to use those ways -- they are just a bit > safer but still lots of cars are running with 100 km/h next to you -- > so I think it would be good to have a way to separate them from other ways > where no major road is close. > > A possible way would be this: > Simiar to the new ResidentialHook which sets the mkgmap:residential tag we > might implement a > hook which collects major roads and calculates an area around it (maybe > 20m on both sides). > Each way (maybe only those with highway=* ) could be checked against those > areas in a way that a rule could > decide to "dislike" a way which is mostly within such an area when the map > is for cyclists. > I guess bridges and tunnels (or more generally the layer tag) needs > special handling here. > > Questions: > 1) Do you think this would good to have? > 2) If yes, what kind of information would be needed in the style? > > Gerd > > > ___ > 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
[mkgmap-dev] Parallel major roads to cycleways
Hi, I just want to share an idea which might be interesting for cycling maps: In Germany and probably also Austria) many major roads have a parallel cycleway close to it, often only separated by a patch of grass or natural=tree_row. Example: A way with bicycle=designated : http://www.openstreetmap.org/way/243499929 runs next to highway=primary B213 http://www.openstreetmap.org/way/328470949 I think nearly no cyclist likes to use those ways -- they are just a bit safer but still lots of cars are running with 100 km/h next to you -- so I think it would be good to have a way to separate them from other ways where no major road is close. A possible way would be this: Simiar to the new ResidentialHook which sets the mkgmap:residential tag we might implement a hook which collects major roads and calculates an area around it (maybe 20m on both sides). Each way (maybe only those with highway=* ) could be checked against those areas in a way that a rule could decide to "dislike" a way which is mostly within such an area when the map is for cyclists. I guess bridges and tunnels (or more generally the layer tag) needs special handling here. Questions: 1) Do you think this would good to have? 2) If yes, what kind of information would be needed in the style? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] if-then-else in style and style options
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 im Auftrag von Dave
Swarthout
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
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
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Andrzej Popowski
mailto: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
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> 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 im Auftrag von
> Andrzej Popowski
> 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
Re: [mkgmap-dev] if-then-else in style and style options
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 im Auftrag von Andrzej
Popowski
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
