Like many others it would seem, I too would like to return associated OSM data for the path returned in the map matching functionality. In my case, for each edge I’d like the WayID and the tags, with the end goal of identifying the Ways and the highway type for each edge. I’ve seen some comments about how Node IDs are better, wouldn’t mind an explanation as to why that is.
It seems/seemed possible, however I think a lot of these posts are a bit out of date and don’t work for graphhopper 3.0. As per the posts:
I’ve created the OSMReaderOSM class in the com.graphhopper.reader.osm package of the core module. Seems ok.
Next I created an OSMGraphHopper class in the com.graphhopper package of the core module, however there are a few compilation issues. The createReader() and calcPaths() methods seem to be gone (get complaints about non existent overridden methods), also there is no DataReader class anymore.
Any idea on how to tweak the previous changes to work in 3.0? Also, how do I get my custom OSMGraphHopper instance to be injected instead of the default one, do I just change lines 55 and 60 in MapMatchingResource to use my custom one instead?
OK, so since there was no guidance for newer versions of GraphHopper on how to modify the snippets to get OSM mapping, I went about trawling through the code to understand what was going on and how to get it working.
I’ve attached a git patch that contains all the required changes for importing and map-matching to have OSM data available in GraphHopper. It may not be the ‘best’ way, but it works. Note that the printOsmWayIds() method isn’t needed, I just added it as a little example/debug utility to show how to get the IDs out.
Thanks again for this Ross.
I am a bit of a newby sorry.
I have installed the same commit and your patch (and checked it applied). Routing and matching work fine – but I have not idea how the get the OSM ID’s out in the JSON.
Can you point me int he right direction, please?
I have tried this and don’t see any change in the output. I have rebuilt the server from scratch and double check the patchs applied.
I then call
curl -XPOST -H “Content-Type: application/gpx+xml” “http://xxx.xxx.xx.xxx/match?vehicle=car&points_encoded=false” --data @test.gpx
and it returns a ‘normal’ json.
I will send you a PM with the actual url incase I am doing something dumb (this is likely sorry).
Hello Ross, I’ve looked over your changes and I see that you use node_mappings to collect the osm node id’s.
The method that you wrote to get the actual osm node id, uses similar logic to get the way ids. I see that in MapMatchingResource, we use the MatchResult to get the edge id’s and then we query the edge_mapping to get the actual way id.
I’m trying to implement the same in RouteResource, but there I don’t have access to edge ids. I can certainly call MapMatchingResource by creating a new request based on the points that are part of the request, but that seems overkill. Is there an easier way to get way id’s being returned in the /route endpoint?
Also, I noticed that the node_mappings file it’s always WAY smaller (almost empty I would say) as compared to the edge_mappings.
If I query node_mappings using edge_id’s I always get ArrayOutOfBounds errors.
In the method that was created in MapMatchingResource to call the new OSMGraphHopper we use int internalEdgeId = match.getEdgeState().getEdge() should I use the same to get the OSMNodeId’s ?