logo separator

[mkgmap-dev] [PATCH v2] Move maxspeed calculations to style file

From WanMil wmgcnfg at web.de on Tue Sep 3 21:16:22 BST 2013

Hi Manfred,

thanks for your proposal. I think there are a lot of reasons why the new 
curviness() function might be a bad idea (it depends on how well a way 
is mapped; its value is unreliable due to the mapping to the garmin 
coordinates; etc.).

Anyhow I think it's worthy to play a little bit with it :-)
I will try to add a first implementation of this function so anybody can 
test it. If it does not get enough supporters we can throw it away later on.

WanMil

> Hi all,
> moving away from fixed built-in, to a flexible, configurable mkgmap can
> give a great progress to the quality of maps.
> You do a great job, and I really appreciate your work
> Thinking about maxspeed:practical, which can be used to initialize
> maxspeed in some cases, I thought about rural areas, which do not have
> any maxspeed, or maxspeed:practical information included in OSM data:
> The new curviness() function (useful for ways).
> Such a function could e.g. return the sum of direction change at every
> point, divided by the way's length.
> This could give an estimation for the maximum practical speed.
> /--------------------------------------------------------
> |     ...
> |     maxspeed!=* & maxspeed:practical!=* & curviness()<0.3 {set
> maxspeed:practical=120}
> |     maxspeed!=* & maxspeed:practical!=* & curviness()<0.5 {set
> maxspeed:practical=100}
> |     maxspeed!=* & maxspeed:practical!=* & curviness()<0.8 {set
> maxspeed:practical=80}
> |     ...
> |     maxspeed:practical=* {set maxspeed=${maxspeed:practical} }
> |     ...
> \------------------------------------------------------------
> However, the values are only fictional values, and does not include a
> physical background. But anyway, it might help improve routing quality,
> especially in poor mapped areas
> It also could help to improve maps for motorbikers, who tend to prefer
> curvy roads.
> Could you imagine that such a function would make sense?
> Cheers
> Manfred
> *Gesendet:* Freitag, 30. August 2013 um 22:19 Uhr
> *Von:* WanMil <wmgcnfg at web.de>
> *An:* "Development list for mkgmap" <mkgmap-dev at lists.mkgmap.org.uk>
> *Betreff:* Re: [mkgmap-dev] [PATCH v2] Move maxspeed calculations to
> style file
>  > Felix> only downwards, is what everyone expects, but not what mkgmap did
>  > Felix> so far. I critisized this quite often in the past....
>  >
>  > Thanks Felix - that's what I wanted to know. I obviously overlooked
>  > your previous complaints!
>  >
>  > The style rules you present do look quite unwieldy - perhaps it's
>  > possible to simplify by setting initial defaults, and using those to
>  > allow revising downwards:
>  >
>  > /--------
>  > | highway=motorway { add mkgmap:road-speed-class = 7 }
>  > | highway=trunk { add mkgmap:road-speed-class = 6 }
>  > | ...
>  > |
>  > | maxspeed:practical=* { set maxspeed=${maxspeed:practical} }
>  > |
>  > | maxspeed=* & mkgmap:road-speed-class > 1 & maxspeedkmh() <= 5
>  > | { set mkgmap:road-speed-class = 1 }
>  > | maxspeed=* & mkgmap:road-speed-class > 2 & maxspeedkmh() <= 20
>  > | { set mkgmap:road-speed-class = 2 }
>  > | ...
>  > \--------
>  >
>  > Is there any reason why that wouldn't work?
>
> Should work.
> As I answered Felix I will come back later on to improve the default
> maxspeed rules.
>
> WanMil
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



More information about the mkgmap-dev mailing list