logo separator

[mkgmap-dev] Road speed through urban areas

From Fernando Trebien fernando.trebien at gmail.com on Wed Jul 8 15:08:36 BST 2020

Thank you Ticker and Greg. Somehow, I didn't get the message from
Ticker in my mailbox, but now I can read it here. [1]

I'm using BaseCamp to test the changes, assuming that Garmin devices
run the same routing algorithm and, therefore, would give the same
result to end users. In the meantime, I modified the default example
style by adding this line at the beginning:

maxspeed:practical=* & maxspeed=* & maxspeed:practical < $maxspeed {
set maxspeed='${maxspeed:practical}' }

And it appears to be working just as expected! Although I think this
rule would not work for maxspeed:practical represented in mph. I tried
to create a rule that substitutes the value of maxspeed with the value
of maxspeed:practical only if maxspeed:practical is lower than
maxspeed. By duplicating that line and replacing "practical" with
"advisory", one gets the behaviour suggested by Greg previously. It
surprises me that currently few routing software supports
maxspeed:advisory (so far I think only OsmAnd supports both
maxspeed:advisory and maxspeed:practical), as this tends to be more
closely related to the expected average speed than maxspeed when both
are present. Similar rules could be written further to support various
values of surface and smoothness, further improving routing in
specific situations. [5][6] In a way, I feel that the lack of
available built-in speed levels between 5 and 20kmph restricts the
ability of Garmin devices to produce high-quality routes in areas with
poorer infrastructure, as is the case in developing countries.

>From Ticker's mention of the is-in function, I found this message [2]
that mentions mkgmap:urban, which sounds like a more general solution
without requiring the maxspeed:practical tag too much. But there's no
mkgmap:urban in the latest code. A definitive solution, though more
complex, would probably require support for traffic patterns. [3][4]
I'll look into the specifics of the is-in function now.

Thank you again. Regards.

[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031264.html
[2] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026124.html
[3] https://wiki.openstreetmap.org/wiki/Global_Statistical_Speed_Matrix
[4] https://github.com/graphhopper/open-traffic-collection
[5] https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
[6] https://github.com/graphhopper/graphhopper/blob/master/core/src/main/java/com/graphhopper/routing/util/CarFlagEncoder.java

On Tue, Jul 7, 2020 at 9:28 AM Greg Troxel <gdt at lexort.com> wrote:
>
>
> > The mkgmap default style doesn't understand maxspeed:practical.
>
> Thanks.  I was unclear on this.
>
> I would suggest that mkgmap should in the default style use the first
> one of these that is defined:
>
>   maxspeed:practical
>   maxspeed:advisory (yellow sign, in the US, not a requirement, but advice)
>   maxspeed (legal limit)
>
> I am unclear on if advisory is used in non-US places.  Here we often
> e.g.  have yellow "45" signs on curves on roads with "55" limit (white)
> signs, and on exit ramps (slip roads in en_GB, *_link in osm).
> Sometimes the advisory speeds are sensible, some times they are way too
> low and occasionally they are too high.  A great case for using
> practical to fix them.
>
>
> I would expect this to be quite necessary in rural UK and IE, as it
> seems there is a tradition of 100 km/h or 60 mph outside town centers,
> but at times roads often narrower/twisty such that at least I didn't
> think it wise.
>
> (The US doesn't do this so much; very rarely is the legal limit unsafe.
> There are dirt roads where :practical should be used, though.)
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



-- 
Fernando Trebien


More information about the mkgmap-dev mailing list