This visualization comes from JOSM, showing all OSM ways returned in a /spt response (using the technique mentioned in Retrieve OSM node and way ID).
I was wondering why not all streets (edges) are present in the result: see the roads with no red line, even though they are as “accessible” as the adjacent ones. Why are they skipped?
Or is it due to a setting somewhere?
Are you self-hosting GraphHopper? Could it be that the roads that aren’t used are not accessible with the vehicle you are using? Which vehicle are you using?
To debug this issue you might want to use ‘Local MVT’ from the layers menu (layer icon on the map) to see the GraphHopper road network on your map (only works if you are starting your own GH server).
Hi easbar, yes, I’m using a self hosted GrahHopper instance.
I’m using “car” as vehicle.
I wasn’t aware that such an option existed to visualize the network with the MVT layer — thanks for the tip!
Here’s what it looks like for the same area as my original screenshot, having selected the road just above the roundabout in the middle of the image:
That’s a pretty regular road as far as I can see: https://www.openstreetmap.org/way/7202103
I’ve tried increasing the value of “time_limit” and “distance_limit” in a /spt request dead on the roundabout, but even then some roads in the vicinity just don’t appear in the result.
Is there a way to debug this issue further down?
Well, yes, but this is because the shortest path tree is exploring nodes (road junctions) not streets. (Sorry initially I thought you are talking about the blank area where none of the roads are discovered in the top left). For example it finds the junctions at which Barkstraat starts/ends, but it finds these junction using different streets and Barkstraat itself is not part of the tree. You could try the edge-based shortest path tree that was added recently (you need to set turn_costs: true in the profile settings (see docs/core.profiles.md)) and it will be enabled automatically.
If you do this it would be nice to get a similar screenshot and maybe we could even use this for the blog post for the 1.0 release (since the edge-based isochrones are a new feature in 1.0)
Yeah, with “turn_costs: true” it works as I expected! Nice, thanks a lot for your help.
Now I can go further with a demo I wanted to build about combining isochrones.