<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Felix,<br><br>please check:<br>I think sharp angles (or angles at all) do only matter at junctions of (different) roads. <br>The RoadMerger should already join similar roads, and the routing algo doesn't care about <br>angles in roads. The reason is quite simple:<br>The NOD file contains no information about the angles within arcs. It only contains information about<br>- position of nodes (in garmin map units)<br>- arcs between these nodes (information: oneway or not, throughrouting or not, allowed vehicles, road class and speed, <br>ratio between way on road and direct connection, and the so called initial heading.<br>For each arc between two nodes n1 and n2 there exists a reverse arc from n2 to n1.<br>So, the routing algo can calculate in which direction a road is going that arrives at a node,<br>and at which direction another road is leaving. <br>The sharper the angle between them, the more likely you see a time penalty when the algo decides to take that way.<br>AFAIK the routing algo only uses the data in RGN (or NET) to determine the overall length of the way,<br>and it seems to calculate that only once for the final result, not for the alternatives.<br><br>The interesting point is that a sharp angle in the way doesn't matter as long as there is no connection to another road.<br><br>I don't know yet how to find the initial headings which have to be changed, but for now it looks much easier to me to<br>manipulate these values instead of adding new nodes and new arcs. Also, this will not change the size of the img file <br>very much. Anyway, also the latter could be done.<br><br>I've create a small test file to find out under what circumstances the routing algo avoids the shorter route, see attachment.<br><br>Gerd<br><br><div><hr id="stopSpelling">Date: Tue, 8 Apr 2014 11:42:02 +0200<br>From: extremecarver@gmail.com<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Subject: Re: [mkgmap-dev] Sharp angles in cycle ways<br><br>
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="ecxmoz-cite-prefix">On 08.04.2014 11:38, Felix Hartmann
wrote:<br>
</div>
<blockquote cite="mid:5343C386.9030102@gmail.com">
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 class="ecxmoz-txt-link-freetext" href="ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtblegend.exe" target="_blank">ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtblegend.exe</a><br>
data: <a class="ecxmoz-txt-link-freetext" href="ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/legend.osm" target="_blank">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="ecxmoz-cite-prefix">On 08.04.2014 10:16, Gerd Petermann
wrote:<br>
</div>
<blockquote cite="mid:DUB112-W1213B0771D1D90E2A4C55579E6B0@phx.gbl">
<div dir="ltr">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
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 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="ecxmimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
mkgmap-dev mailing list
<a class="ecxmoz-txt-link-abbreviated" href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
<a class="ecxmoz-txt-link-freetext" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></pre>
</blockquote>
<br>
<pre class="ecxmoz-signature">--
keep on biking and discovering new trails
Felix
openmtbmap.org & <a class="ecxmoz-txt-link-abbreviated" href="http://www.velomap.org" target="_blank">www.velomap.org</a></pre>
</blockquote>
<br>
<pre class="ecxmoz-signature">--
keep on biking and discovering new trails
Felix
openmtbmap.org & <a class="ecxmoz-txt-link-abbreviated" href="http://www.velomap.org" target="_blank">www.velomap.org</a></pre>
<br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div> </div></body>
</html>