<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Oh yeah - just to give an example:<br>
<br>
The very sharp angle at road_speed=2 is already enough to add 2
minutes to the time vs the same distance on ~15° angle!!!!<br>
(which is completly unrealstic to lose 2min for one single turn if
you are only at 40km/h (road_speed=2) anyhow...)<br>
<br>
<br>
<div class="moz-cite-prefix">On 08.04.2014 11:38, Felix Hartmann
wrote:<br>
</div>
<blockquote cite="mid:5343C386.9030102@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Well I used rather my own data for tests - and not OSM.... <br>
The only problem is that - while I can see that sharp angles add
an tremendous amount of time to the route calculation, and are
usually avoided, I cannot really see the influence on long
distance routing. Because there are 3 factors to consider:<br>
1. Sharp turns in angles<br>
2. Preference for straight roads even if no intersection (doesn't
seem to be too strong)<br>
3. Overall turns (also doesn't seem to matter that much - though
it ends up being about 100 to 150 turns limit between actual route
points given by the user).<br>
<br>
There is some sort of cut off angle. I think any angle over 170°
actually creates routing mistakes. They need to be angled lower in
any case anyhow...<br>
<br>
<br>
You can play around a bit here: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtblegend.exe">ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtblegend.exe</a><br>
data: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/legend.osm">ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/legend.osm</a><br>
<br>
<br>
The main importance regarding this is road_speed. (for above
example). Have a look at the top roads which sometimes have
supershort angles<br>
While on the top left the Roundabout is roadspeed 0 - the sharp
turn doesn't matter. <br>
For the top middle track roads - which have roadspeed=2 - the
sharp turns create far too big penalties.<br>
<br>
<br>
Actually the penalty for a 170° turn on intersection with
roadspeed=7 is 5 minutes or so. That's absolutely unrealistic
(because in real life at such an intersection everyone would be
slowed down reasonably, so also cars going straight would need to
go slower)...<br>
<br>
<br>
<br>
So no - I would not like to have 90° everywhere - but actually
additional very short insible arc ways for very sharp turns. Say
every intersection over 110° should be arced to get it down
(creating two intersections that are both small angle)...<br>
For places where there is no actual intersection - but only two
roads meeting at sharp angle (e.g. a hairpin turn where in osm
there are two lines meeting at the hairpin - which is actually
quite common) best would be of course to join the two roads and
maybe additionally make the hairpin a bit rounder. If joining is
not possible then just make it rounder...<br>
<br>
<br>
<br>
As I don't know if some of my proposals are easy or easier than
others, it would be nice to give any of them a try to see if it
improves routing...<br>
<br>
<br>
So concluding:<br>
1.V shaped unreal intersection or just very tight V turn: smooth
it out. Join if possible<br>
2. Y shaped intersection. Add additional invisible arc way to
smoothen the sharp angle out.<br>
3. X shaped intersection or intersections with even more routable
lines meeting - same as 2. would be great <br>
(in cities that would even reflect reality better as usually turns
are not so sharp - but often due to simplicity in mapping - the
ways meet at one point in OSM - however due to micro mapping
theese become less common anyhow).<br>
<br>
If the style adds multiple routable ways for one OSM way, the
corresponding<br>
multiple arcs between nodes on that way should be counted like one
.<br>
- Yep, only one additional arc should be created. The
roadspeed/roadclass should be highest minus 1. <br>
Actually I think if 1-3 could all be handled by mkgmap - I could
skip most of my additional routable ways (save differing speed
depending on direction) - as they only exist to increase chances
that curvy/turny routes are calculated - as the main problem is:
If you create a highway with road_class=4 and road_speed=7
(road_speed being the main problem) - and it's turny/curvy it
simply won't be used by Garmin (the first assumption that you
would use to make a cycle route into the most preferred way). If
it is road_class=4 and road_speed=2 or 1 - it is much more
attractive to the algo - albeit loosing out on long distance.
Hence creating multiple routable lines of the same way, increases
the chance that one of it fits...<br>
And while it's actually still quite easy to build the map in such
a way that relation=route / route=cycleway has high preference -
it currently is more or less impossible to create a map that has
highest preference for highway=path (because pathes don't form any
network).<br>
<br>
<br>
<div class="moz-cite-prefix">On 08.04.2014 10:16, Gerd Petermann
wrote:<br>
</div>
<blockquote
cite="mid:DUB112-W1213B0771D1D90E2A4C55579E6B0@phx.gbl"
type="cite">
<div dir="ltr">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Hi all,<br>
<br>
a few days ago Felix suggested to add code to improve
routing for bicycles:<br>
<a moz-do-not-send="true"
href="http://gis.19327.n5.nabble.com/r3165-in-via-ways-branch-tp5802056p5802063.html"
target="_blank">http://gis.19327.n5.nabble.com/r3165-in-via-ways-branch-tp5802056p5802063.html</a><br>
<br>
If I got that right, mkgmap should detect cases where two
arcs meet at with a sharp angle <br>
and the arcs are only accessible by bicycle or foot. In such
a case, mkgmap should<br>
"manipulate" the angle so that the routing algo doesn't add
too much time penalty,<br>
as we can assume that the real angle is not that sharp.<br>
<br>
Or mkgmap should assume that the created map is for cyclists
only, so that car access<br>
means something like racing bike.<br>
<br>
Optimization would work like this:<br>
1) at an y-shaped node, find the two arcs which are closer
to a straight line and modify the <br>
initial heading of the other arc so that Garmin sees a right
angle (90°) .<br>
2) at an x -shaped node, try to make all angles 90°<br>
3) at nodes with more than 4 arcs, do nothing.<br>
<br>
If the style adds multiple routable ways for one OSM way,
the corresponding<br>
multiple arcs between nodes on that way should be counted
like one .<br>
<br>
If that can be coded, it has only to be done if a new option
like --optimize-cycle-ways is given.<br>
<br>
Did I get that right? <br>
<br>
@Felix:<br>
Please provide a test case (the OSM id of a node ) <br>
<br>
Gerd<br>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mkgmap-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
keep on biking and discovering new trails
Felix
openmtbmap.org & <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.velomap.org">www.velomap.org</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
keep on biking and discovering new trails
Felix
openmtbmap.org & <a class="moz-txt-link-abbreviated" href="http://www.velomap.org">www.velomap.org</a></pre>
</body>
</html>