[OSRM-talk] adding way id and direction to output
Jens Thiele
karme at karme.de
Tue Apr 30 13:53:12 UTC 2013
Emil Tin <emil at tin.dk> writes:
> On Apr 30, 2013, at 10:44 , Jens Thiele <karme at karme.de> wrote:
>
>> Emil Tin <emil at tin.dk> writes:
>>
>>> I fixed these and added a few tests.
>> ok
>>
>> similar place where i am not sure it is correct:
>> ./GraphLoader.h:150: std::swap(forward, backward);
>>
>> and a place where i am confused:
>>
>> BasicRoutingInterface.h:147: unpackedPath.push_back(_PathData(ed.id,
>> _queryData.nodeHelpDesk->getNameIndexFromEdgeID(ed.id),
>> _queryData.nodeHelpDesk->getTurnInstructionFromEdgeID(ed.id),
>> ed.distance, _queryData.nodeHelpDesk->getModeFromEdgeID(ed.id)) );
>>
>> does it matter whether the code above matched the edge in forward or
>> backward direction? maybe one condition is always false? it is
>> always used in forward direction? - but maybe I do have some
>> misconception here.
>
>
> when unpacking the path, what's referenced with an id is edge based
> edges, and they're always unidirectional.
i see, thanks!
> did you try running the mode flag tests? they all pass:
>
> cucumber -t @mode
not yet, sorry - on my main development machine i don't have ruby / gems
> of course there might be other cases that doesn't work correctly. if
> you can find them and write a failing test, it's always helpful.
will try if i find a problem
>>> On a sidenote, I think the way.direction flag could be removed from
>>> LUA. Instead you could just set forward and backward speed.
>> do you also think removing it completely would be a good idea?
>
> internally we need a way to speciify whether an node based edge is
> bidirectional. whether we use a single direction flag, or separate
> forward/backward flags i don't think matter so much.
at that point i only meant removing way.direction to make the lua
profiles simpler
greetings
jens
More information about the OSRM-talk
mailing list