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