On Apr 30, 2013, at 10:44 , Jens Thiele <[email protected]> wrote:

> Emil Tin <[email protected]> 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.

did you try running the mode flag tests? they all pass: 

        cucumber -t @mode

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.




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



> jens
> 
> _______________________________________________
> OSRM-talk mailing list
> [email protected]
> http://lists.openstreetmap.org/listinfo/osrm-talk


_______________________________________________
OSRM-talk mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/osrm-talk

Reply via email to