Hello,
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.
To apply the changes to your codebase, run git apply osm-mapping.patch. For the record, this was for commit e919a9415b591478b14a7c37be6249586fb740f on the master branch.
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?
Thanks
Apply this one as well. I just was playing around and this just lists OSM Way IDs at the root of the JSON, but you can fiddle with the code as you like to get the kind of output you want.
Thanks Ross
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).
okay – my bad
need to run ./graphhopper.sh --action clean
(I had tested the install before apply the patches – but clean clears the jar file and then rebuilds on next start).
Newby error
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 ?
