Update speedy routers and tree for turn restrictions

[nkuehnel]

Updates the speedy code for turn restrictions

• if we land on a colored node copy in point-to-point search, we will (sometimes?) not have reached/visited the "real" node. However, when constructing the path, we depend on data being present in the index of the "real" node whereas it is only set for the colored copy, causing infinite loops in the construct paths. Instead we can just replace the endnodeindex with the colored version for constructing the path
• similarly, in the tree version (heavily used by dvrp/drt for matrices), we might not even hit the real node at all, because there are cases where we only have colored copies of a node. This means the travel time will stay at inifinity, causing the dvrp travel time matrix to crash. Also we might reach a colored version earlier. As such, go through all colored copies and possibly replace the travel time of the uncolored "real" node

[nkuehnel]

in the ALT version we might need to dig a bit deeper because it can happen that a landmark:

• is selected for a "real node" that is not reachable (only its colored copies), leading to infinities
• is reachable from the source and to the target. but because of turn restrictions the actual route is longer than the sum of these two, in which case the inequality might not hold true anymore?

[nkuehnel]

Trying to explain with a simple (and surprisingly common in real-world network) example. Given this (sub)graph of 6 nodes A-F. If we have two opposing U-turn restrictions at node C (meaning C-A is disallowed coming from A-C and C-E is disallowed coming from E-C) we replace the two start links (shown dashed like in https://github.com/matsim-org/matsim-code-examples/wiki/turn-restrictions) with colored links and colored node copies C' and C''. Node C is still a 'valid' real starting node for the one-way link C-D.

In the expanded colored network there is now no way to route to the "real" node, you can only get to C' or C''. As such, in the LeastCostPathTree there will be no data for node C, just for its colored copies. However, reaching C' or C'' should be just as valid as reaching C. Thus, the lowest cost for either reaching C' or C'' should be taken into account when querying the travel time/cost to C.

Similarly, the point to point routing algorithms already caught the case where we reach a colored copy of the end node:

// if turn restrictions are used, we might be on a colored node, so check for the original node
if (hasTurnRestrictions && this.graph.getNode(nodeIdx).getId().index() == endNodeIndex) {
	foundEndNode = true;
	break;
}

However, if we never reached the "real" node before, the construct path will fail as it turns into an infinite loop due to the lack of data being present in the respective arrays (comingFrom and usedLink):

private Path constructPath(int endNodeIndex, double startTime) {
		double travelCost = getCost(endNodeIndex);
		double arrivalTime = getTimeRaw(endNodeIndex);
		if (Double.isInfinite(arrivalTime)) {
			throw new RuntimeException("Undefined time on end node");
		}
		double travelTime = arrivalTime - startTime;
		List<Node> nodes = new ArrayList<>();
		List<Link> links = new ArrayList<>();
		int nodeIndex = endNodeIndex;
		nodes.add(this.graph.getNode(nodeIndex));
		int linkIndex = this.usedLink[nodeIndex];
		nodeIndex = this.comingFrom[nodeIndex];
		while (nodeIndex >= 0) {
			nodes.add(this.graph.getNode(nodeIndex));
			links.add(this.graph.getLink(linkIndex));
			linkIndex = this.usedLink[nodeIndex];
			nodeIndex = this.comingFrom[nodeIndex];
		}
		Collections.reverse(nodes);
		Collections.reverse(links);
		return new Path(nodes, links, travelTime, travelCost);
	}

A possible solution is to just point to the data which led to the discovery of the colored copy.

[mrieser]

Thanks for those improvements and the explanations today. This looks good to me!