Re: [mkgmap-dev] if-then-else in style and style options

[Andrzej Popowski]

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

[Dave Swarthout]

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

[Gerd Petermann]

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

[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  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 
> 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

Re: [mkgmap-dev] if-then-else in style and style options

[Dave Swarthout]

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

[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  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

Re: [mkgmap-dev] Is any mapper using custom Icons, not displaying labels, but still allows GPS to search by labels?

[osm]

Hi Greg

No , nothing to do with the language label.

With TYP files you can change the font size of your labels - confusingly 
they have been given the name :extended labels


when you dbl click on an icon you can change the fontsize of your labels 
(extended labels) to small , large,normal, default and nolable


Note that certain types do not respond to small,large,normal but only to 
default and nolabel


When you select nolabel the icon label will not be displayed.

It will *not *remove the mgmap:label so you can still search for it


On 15/03/2017 22:21, greg crago wrote:
Nick, is that for the Language Label (0x04 english) label? Something 
you can add to your TYP file with TypWiz5

Will this remove the NAME tag from OSM (mkgmap:label:1)

Greg

On Tue, Mar 14, 2017 at 9:53 PM, nwillink > wrote:


You can set the icon's extended label to 'nolabel' in your TYP file.

r

Nick



--
View this message in context:

http://gis.19327.n8.nabble.com/Is-any-mapper-using-custom-Icons-not-displaying-labels-but-still-allows-GPS-to-search-by-labels-tp5893152p5893156.html


Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
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


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev