You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not satisfied here. We would need to break API again if we have to calculate time, distance, transfers, weight in a routing algo like Dijkstra. Currently we just calculate the weight.
Now I'm thinking about a new class WeightingResult with time, distance, weight, ... and just one method:
classWeighting {
voidcalculate(WeightingResultres, EdgeIteratorStateedge, booleanreverse, intprevEdge);
// or for easier backward compatibility returning the first parameter:// WeightingResult calculate(WeightingResult, EdgeIteratorState, reverse, prevEdge);
}
Then we could easily fill the time or weight etc in this method. It would be even more customizable as we could subclass WeightingResult and add parameters. We could even replace TurnWeighting when we store the turnCosts in the WeightingResult (or a subclass).
Another advantage is that we currently would calculate the weighting and then the 'millis' but this work of calculating the time is already (often) done in calculating the weighting and so it would be duplicative which we can avoid via this new method.
One problem remains: how we incorporate the time stuff currently required for the pt branch.
We can avoid the reverse parameter if that is handled from the EdgeIterator:
iter = explorer.setBaseNode(node, reverse);
The text was updated successfully, but these errors were encountered:
Copied from PR #807
I'm not satisfied here. We would need to break API again if we have to calculate time, distance, transfers, weight in a routing algo like Dijkstra. Currently we just calculate the weight.
Now I'm thinking about a new class
WeightingResult
with time, distance, weight, ... and just one method:Then we could easily fill the time or weight etc in this method. It would be even more customizable as we could subclass WeightingResult and add parameters. We could even replace
TurnWeighting
when we store the turnCosts in the WeightingResult (or a subclass).Another advantage is that we currently would calculate the weighting and then the 'millis' but this work of calculating the time is already (often) done in calculating the weighting and so it would be duplicative which we can avoid via this new method.
One problem remains: how we incorporate the time stuff currently required for the
pt
branch.We can avoid the
reverse
parameter if that is handled from the EdgeIterator:iter = explorer.setBaseNode(node, reverse);
The text was updated successfully, but these errors were encountered: