logo separator

[mkgmap-dev] sharp angles and routing

From GerdP gpetermann_muenchen at hotmail.com on Sat Aug 22 08:14:59 BST 2015

Hi all,

I've found some rules and started to code. The results of the first
working version using the default style looked promising.

My approach:
1) For each routing node collect all direct arcs to other nodes
2) sort these arcs by initial heading (IH)
3) check the angle between two consecutive arcs, when it is too small:
 3a) ignore the sharp angle when road speed of both is 0
 3b) ignore the sharp angle when no vehicle is allowed to travel both arcs.
   - check oneways,
   - check access (car, bicycle, foot etc)
   - check route restrictions (from restriction relations or barriers)

 4) For both arcs that build the sharp angle: calculate the angle to the
next arc (before / after)
   If these angles are big enough, change the corresponding initial heading
value
   of the arc so that the sharp angle is enlarged and the large angle is
made a bit more sharp.
   
This seems to work quite well with the default style as long as
--make-opposite-cycleways
is not used. With --make-opposite-cycleways we sometimes see two arcs with
the same IH
but different different results for the 3a) and 3b) check. The angle between
these two arcs
is - of course - 0 (zero).
The cycle map styles like those from Minko or Felix will be even more
complex (or not ?).

To solve this problem I can combine the arcs again so that all arcs which
are 
based on the same OSM way appear only once when calculating angles.
If the heading of such a combined arc is changed, I just have to make sure
that all
corresponding arcs are changed.

My problem:
In most cases the combined arcs will have different routing attributes, so
the 
code for the checks in 3b) will be very complex or they have to be ignored.

Any ideas? Maybe I don't see the wood for the trees?

Gerd




GerdP wrote
> Hi Felix,
> 
> My current approach is to evaluate the results of the style, so it is up
> to the author to decide what
> a pedestrian-only way is. 
> Another point is that we don't need the check for ways which can't be
> accessed
> by bike. I am aware that these checks must be ignored when a special
> cycling 
> map is created (or any other special map, we just have to find out
> meaningful 
> option names)
> 
> I am trying to produce test data to find out in what case Garmin prefers a
> small detour,
> this should help to find concrete rules.
> 
> Gerd





--
View this message in context: http://gis.19327.n5.nabble.com/sharp-angles-and-routing-tp5852065p5852884.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.


More information about the mkgmap-dev mailing list