[GraphHopper] Understanding GraphHopper Instructions

[Peter]

> So again - e.g. if there is a different edge attribute (then name)
that could be used/check,
> I would be more then fine to use that... The only reason why I used
that name-attribute was,
> that I did not found much else in the gh sources (except Instruction
List) that is using it...
> So my thought was, to have as less (unknown) side effects as possible :-)

You could create a new property for your usecase e.g. via
encoder.get/setLong and then check that in the Path code.

But I fear this won't get into GraphHopper itself as this is not easy.
Good instructions will also need the street type (easy) and junction
layout (not that easy now for CH) but at the same time they should not
be expensive to create, really hard if you have long routes.

Regards,
Peter.

> Hi Peter,
>
> thanks for your time to reply - since I am not 100% confident, if I
> have fully understood the core data (yet) I can't answer with a clear
> 'yes' to your question, if I want to have turn instructions after
> every edge (simply cause I don't know the true meaning of 'edge').
>
> If an 'edge' in the object world of graphhoper (gh) is what I would
> call 'a junction or a join' of roads (paths, tracks, trails etc) in
> the real world, then indeed that's what I am looking for (some sort
> of)...
>
> I want to have a instruction every time when I need to "change" the
> current trail I am riding on...
>
> When I started the Thread, I did not understood much - concerning how
> gh is working. Since with the two given example links I hope it's
> quite obvious that there are situations when Instructions are simply
> missing. While I was playing around with different kind of vehicles
> and urban and outdoor sections, I came to the conclusion, that the
> InstructionList generation works solid for urban areas - but not for
> random hiking paths (or country lanes).
>
> Finally I realized what was (is?) IMHO the root cause of the missing
> (or let me say "my missed") instructions - gh is checking for name or
> attribute changes of the edges of the complete graph... Which explains
> that it works very good for urban areas (where every street/path comes
> with an name) - but also seams to be the root of my issue of missing
> instructions for hiking path (and MTB trails) that most of the time
> are unnamed in OSM.
>
> So my thought/suggestion is, to give every edge that will be parsed
> from the OSM data a name - (might be there is already something like a
> uniqueID that can be used for this purpose?!) - since then The
> InstructionList generating code can 'detect' changes between 'unnamed'
> OSMWays (with identical attributes)...
>
> Of course this change have an massive effect on the file size of the
> 'names' storage - e.g. for complete 'hessen' it grew from 3MB to 16MB...
>
> After I have sorted now my thoughts again - When you asked, if I want
> to have a turn instruction for every edge - the answer would be 'no' -
> not for every - when it's straight ahead (CONTINUE_ON_STREET) I don't
> want a Instruction...
>
> So again - e.g. if there is a different edge attribute (then name)
> that could be used/check, I would be more then fine to use that... The
> only reason why I used that name-attribute was, that I did not found
> much else in the gh sources (except Instruction List) that is using
> it... So my thought was, to have as less (unknown) side effects as
> possible :-)
>
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140629/20e2ac34/attachment.html>