Supporting multiple road networks with DataFlagEncoder

Hi Peter,

In my project I have a custom flag encoder that extends the DataFlagEncoder to use road attributes for routing (as extended in my PR I need to support multiple truck types each of which has its own road network but all of them share the same road attributes. For this to work, in my custom flag encoder, I have 1 bit-length encoder for each truck type. acceptWay() will accept a way which is acceptable to any road network and the weighting will return INFINITY when an edge does not belong to the road network in question.

Things seemed to be fine as I was able to find routes within each individual road network. However, there are cases when the start point being resolved to an edge of one network and the end point being resolved to an edge of another network. Consequently, GraphHopper wasn’t able to find a route.

I think the core issue is at ViaRoutingTemplate.lookup() method where the closest edges for the points are looked up. The DefaultEdgeFilter is initialized inline and it accepts an EdgeIteratorState based only on backward/forward properties of the encoder. So I don’t have a way to reject an edge if it does not belong to a network in question.

What do you suggest to overcome this problem? And fundamentally, is my way of incorporating multiple road networks into one flag encoder the right choice for my problem?


Yes, this is ugly. So we need a Weighting instead of the FlagEncoder be passed into the EdgeFilter for the LocationIndexTree or something similar. See the issue #729

Thanks Peter.

So I guess my solution of incorporating multiple road networks into one flag encoder will not work until the quoted issue is implemented.

And if you implement a custom EdgeFilter and we would slightly refactor ViaRoutingTemplate.lookup() before to accept an EdgeFilter instead of a FlagEncoder?

That would be awesome. When would you be able to do the refactoring? I don’t think it will take much time for me to create a custom EdgeFilter.

Sorry, not sure. Currently too many too high priority things are on the table.

No problem. Thanks Peter. I might have a look at the refactoring myself and get your opinion if this feature becomes critical to us.