[GraphHopper] Understanding GraphHopper Instructions

[Matthias Marquardt]

... I think I have already found it :-)

com.graphhopper.routing.util.EncodingManager.applyWayTags(...)

right?!


2014-06-28 16:04 GMT+02:00 Matthias Marquardt <marquardt24 at gmail.com>:

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



-- 
Matthias Marquardt
http://about.me/matthiasmarquardt

[FileScout | iMazing | Iconify | TOMPlayer | LittleBrother | GPSLogger II |
GPSiesConnect]
http://www.emacberry.com
 <http://about.me/matthiasmarquardt>
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140628/577e6751/attachment.html>