Adding extra information to store highway type in the graph

Developers
1

Hi,
I need to get access to the highway type (e.g. motorway, primary) of the nodes in a map-matched route for some extra processing, but I’m struggling to work out how. What I’d like is to be able to have a clean lookup from some code iterating over the information in a MatchResult object.

From reading the forum it looks like a new FlagEncoder is required to do this, but all the posts only have code fragments, and not a complete picture of what is needed to achieve this.

I think the answer is along the lines of:
a) add the new encoder string into routing/util/FlagEncoderFactory.java
b) create the new encoder class, extending off an existing one as appropriate, ensuring the “toString” method returns the string added to the factory
c) define methods defineWayBits, handleWayTags and applyWayTags (I guess this is for the OSM parser to use to encode the data into the GraphHopper format)

I’ve not seen a method for being able to read the new data, and neither is it clear how to access this from entries in a MatchResult.

Can anyone provide more detail to this?
Thanks

2

We know this is too complicated and are working on something that makes storing properties for every edge much easier: Edge flags refactoring by karussell · Pull Request #1447 · graphhopper/graphhopper · GitHub

And not only this, there will be certain defaults like highway (road_class), ferry&bridge (road_environment) and surface that will be added as default properties.

In branches like here we are going even further and one can define new vehicles based on a configuration file. See this recent discussion: Disabling CH not allowed on the server-side? - #5 by karussell

I’ve not seen a method for being able to read the new data, and neither is it clear how to access this from entries in a MatchResult.

Currently this is possible via edge.getFlags (e.g. encoder.getDouble(edge.getFlags)) in future versions this will be edge.get(roadClassEnc). Also we’ll automatically create path details for such properties and they’ll be available in the response.

3

Well, I’m certainly looking forward to the merge of 1447 :slight_smile:

In the mean time, I was looking at the encoder.getDouble() call and the only signatures I find also have a second argument (int key). Poking around, it seems we need to define a key int in each class where we add information to the encoder, and these keys need to be unique to the class hierarchy, so that we can break out at the correct level and provide the relevant decode.

Adding this in now gets me something that seems to be working - thanks for the hints (and thanks for all the hard work being put into GraphHopper!)

4

Well, I’m certainly looking forward to the merge of 1447 :slight_smile:

This branch is relative certain that it will get merged as all our tests are positive for now, but we need a bit feedback before merging, as this is a bigger refactoring.

Yes, that is the reasoning here and you already feel: it is not too clean :wink:

Adding this in now gets me something that seems to be working - thanks for the hints (and thanks for all the hard work being put into GraphHopper!)

Happy to hear this!