[GraphHopper] Understanding GraphHopper Instructions

[Matthias Marquardt]

Hello,

my name is Matthias - 43 year old guy from the Bielefeld area. I want to
make use of your offer 'do not hesitate to ask questions' - I am at the
begin of a none commercial outdoor project - before I am going into details
[what I plan to do, and why I expect that GraphHopper is just the 'right'
thing (beside the fact that's pure Java and I am lazy too!)] - I am
currently focusing on the instruction list functionality.

At the beginning I had difficulties to understand why they are, like they
are - when it comes to short trails like this one:

http://graphhopper.com/maps/?point=51.271743%2C8.648402&point=51.274045%2C8.646782&vehicle=bike2&elevation=true

I am missing at least one (IMHO essential) turn in the resulting
instruction list (in the last section of the path (shortly after leaving
the woods) - without knowing too much details about the used OSD from that
specific area I am even more confused when I move the endpoint to the other
path...

http://graphhopper.com/maps/?point=51.271743%2C8.648402&point=51.274421%2C8.648252&vehicle=bike2&elevation=true

Still only two turns - and the (IMHO essential) instruction is missing -
actually my "expectation" would be, that I would get four (or even five)
turning instructions for this small route.

Lucky enough the GraphHopper sources are available, so I made my way though
the calls (while having the code running in my IDE debugger) and realized
the root of my "issue" is in the com.graphhopper.routing.Path class - to be
more precise in the lines 416, 417 and 418 (in the 'forEveryEdge' code)

                    if ((!name.equals(tmpName))
                            || (!annotation.equals(tmpAnnotation)))
                    {

While the graph in the given example has six edges the resulting list of
instructions will be so short simply cause the edge objects does not have
any names AND no essential differences in their annotations - this even
explains instantly, why when switching over from bike to foot, that I get
zero turning instructions at all, since the foot encoder does not not make
any differences in the annotations...

So with other words (moving away from the java object world back to the
real world) - the current GraphHopper version give you only instructions,
IF there is a significant change between the edges [like street name
change, or change from tarmac to gravel] - I do not doubt, that the chosen
implementation is the right way by default - a quick test (removing the
name & annotation check) showed me that with my hacked code, the
instruction list result is finally matching "my expectation".

My question right now is, since I have realized, that the extracted data is
IMHO the root cause of the issue, in which area of the code I have to dig
for the portion, that is responsible for creating the base data from which
later the edges are created - since my next attempt would be to give every
path that will be extracted from the OSM data a unique name (if not
present) - or would that be a silly idea?! [I think I will add a prefix, so
that when the name later will be used, it can be detected, that this is
just a "internal name" - and that instructions like 'turn left to
MyUUIDPrefix_243211' could be avoided']

TIA - Matthias
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140628/b82413b1/attachment.html>