[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