Take routing algorithm factory out of PrepareContractionHierarchies
#1819
Conversation
# Conflicts: # core/src/main/java/com/graphhopper/routing/ch/NodeBasedNodeContractor.java
…e edge-based witness path searcher
# Conflicts: # core/src/main/java/com/graphhopper/routing/ch/EdgeBasedNodeContractor.java # core/src/main/java/com/graphhopper/routing/ch/EdgeBasedWitnessPathSearcher.java # core/src/test/java/com/graphhopper/routing/ch/EdgeBasedWitnessPathSearcherTest.java
# Conflicts: # core/src/test/java/com/graphhopper/routing/ch/PrepareContractionHierarchiesTest.java
# Conflicts: # core/src/main/java/com/graphhopper/routing/ch/PrepareContractionHierarchies.java
| } | ||
|
|
||
| private TurnWeighting createTurnWeightingForEdgeBased(Graph graph) { | ||
| // important: do not simply take the turn cost storage from ghStorage, because we need the wrapped storage from |
There was a problem hiding this comment.
Do you know what this comment was meant for?
There was a problem hiding this comment.
Yes. If graph is a QueryGraph (not just a CHGraph) we have to use QueryGraphTurnCostStorage which provides some special handling for virtual nodes (do not apply turn costs) and converts the virtual edge ids to the underlying real edge ids before getting the turn costs from the actual turn cost storage. This is a problem also for #1820, because it means that TurnWeighting is not just another Weighting but it uses information that is only available after the query graph has been constructed. This works because currently we always create a TurnWeighting for each request (compared to the Weighting objects that always live in CHDecorator/CHProfile), but if we want to include calcTurnWeight etc. in Weighting this is a problem.
There was a problem hiding this comment.
Now I understand - thanks!
This is a problem also for #1820
Yeah, I stumbled over this already in #1775
it means that TurnWeighting is not just another Weighting but it uses information that is only available after the query graph has been constructed
This is interesting. The BlockAreaWeighting is similar: it requires a query graph. But when I thought about it in more detail I found that it could use a base graph and just throw an exception if query points are inside the blocked areas, which should help to resolve the dependency problem (QueryGraph->BlockAreaWeighting, LocationIndex->BlockAreaWeighting and LocationIndex->QueryGraph).
but if we want to include calcTurnWeight etc. in Weighting this is a problem.
You mean for CH this is a problem? Because for non-CH we already create a Weighting per request.
There was a problem hiding this comment.
You mean for CH this is a problem? Because for non-CH we already create a Weighting per request.
Yes I meant for CH (or at least this is the one place where I know its problematic, not sure if there are other places).
This PR puts the CH algorithm factory into a separate class instead of making
PrepareContractionHierarchiesa routing algorithm factory. With this change I was able to change thePrepareContractionHierarchiesconstructor to what I think it should look like now:We get the base graph (
GraphHopperStorage) and aCHProfileand our goal is to create a CH preparation (aCHGraphcurrently) for this profile on the base graph. This is all this class should be concerned with. Creating an algorithm on an already prepared CH graph is another story and now done inCHRoutingAlgorithmFactory. I still keptPrepareContractionHierarchies#getRoutingAlgorithmFactory()for convenience for now.