[mkgmap-dev] Sharp angles in cycle ways

Tue Apr 8 10:38:14 BST 2014

Well I used rather my own data for tests - and not OSM....
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:
1. Sharp turns in angles
2. Preference for straight roads even if no intersection (doesn't seem 
to be too strong)
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).

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

You can play around a bit here: 
ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtblegend.exe
data: ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/legend.osm

The main importance regarding this is road_speed. (for above example). 
Have a look at the top roads which sometimes have supershort angles
While on the top left the Roundabout is roadspeed 0 - the sharp turn 
doesn't matter.
For the top middle track roads - which have roadspeed=2 - the sharp 
turns create far too big penalties.

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)...

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)...
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...

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

So concluding:
1.V shaped unreal intersection or just very tight V turn: smooth it out. 
Join if possible
2. Y shaped intersection. Add additional invisible arc way to smoothen 
the sharp angle out.
3. X shaped intersection or intersections with even more routable lines 
meeting - same as 2. would be great
(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).

If the style adds multiple routable ways for one OSM way, the corresponding
multiple arcs between nodes on that way should be counted like one .
- Yep, only one additional arc should be created. The 
roadspeed/roadclass should be highest minus 1.
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...
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).

On 08.04.2014 10:16, Gerd Petermann wrote:
> Hi all,
>
> a few days ago Felix suggested to add code to improve routing for 
> bicycles:
> http://gis.19327.n5.nabble.com/r3165-in-via-ways-branch-tp5802056p5802063.html
>
> If I got that right, mkgmap should detect cases where two arcs meet at 
> with a sharp angle
> and the arcs are only accessible by bicycle or foot. In such a case, 
> mkgmap should
> "manipulate" the angle so that the routing algo doesn't add too much 
> time penalty,
> as we can assume that the real angle is not that sharp.
>
> Or mkgmap should assume that the created map is for cyclists only, so 
> that car access
> means something like racing bike.
>
> Optimization would work like this:
> 1) at an y-shaped node, find the two arcs which are closer to a 
> straight line and modify the
> initial heading of the other arc so that Garmin sees a right angle 
> (90°)  .
> 2) at an x -shaped node, try to make all angles 90°
> 3) at nodes with more than 4 arcs, do nothing.
>
> If the style adds multiple routable ways for one OSM way, the 
> corresponding
> multiple arcs between nodes on that way should be counted like one .
>
> If that can be coded, it has only to be done if a new option like 
> --optimize-cycle-ways is given.
>
> Did I get that right?
>
> @Felix:
> Please provide a test case (the OSM id of a node )
>
> Gerd
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140408/1aaac5ec/attachment.html>