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.
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.
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.
Well, I’m certainly looking forward to the merge of 1447
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!)
Well, I’m certainly looking forward to the merge of 1447
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
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!)