Location Service Very Sensitive to Search Filters for Bicycle Cost

[moss-xyz]

Not sure if there's anything to be done about this, but wanted to flag something odd I came across as I was try to analyze O-D pairs: Valhalla seems to have a rough time using the Locate API (Loki?) when the cost mode is set to Bicycle.

What I mean is that I often get error messages about No suitable edges near... for a given request (either for an O-D trip or an isochrone), but I can seemingly get around this error by changing the search_filter options for that request location, namely for min_road_class and max_road_class.

Frustratingly, it seems that a different combination of min and max is necessary for each location, to get it to "snap" properly: some that I have used include:

• min: residential, max: primary
• min: tertiary, max: primary'
• min: secondary, max: primary
• min: primary, max: primary
• min: secondary, max: secondary
• min: tertiary, max: tertiary

My question might be: why is this the case? For instance, if my min and max are set to residential and primary, why does changing the min primary sometimes solve the issue? Shouldn't Valhalla already be searching the primary tree for suitable locations?

Additionally, I'm checking these same routes with auto and pedestrian modes, and it seems to have no issue with those: what is it that is particular about the bicycle mode that makes it more prone to fail? I would imagine I could take a bike almost anywhere I am a pedestrian (sans stairs, easily at least)...

I've also changed the radius and minimum_reachability around, but that doesn't consistently fix the issue, whereas the search_filters does seem to.

[dnesbitt61]

can you provide some examples where you get incorrect behavior (No suitable edges ...)?

[moss-xyz]

Sure, here's an example file with some points I can't get bike locating to work at: block_centroid_issues.zip

Actually, as I was going through the process to generate this file, I was able to dig into the error code a little bit, it seems like it is caused by the following: GraphTile DirectedEdge index out of bounds: 711742,3,25464 directededgecount= 25383? Does that mean anything significant?

I noticed that the areas I'm having problems with seem to cluster spatially, so not sure what is happening to these quite large spaces where the graph is failing for bicycle in particular (it works with car and ped).

[nilsnolde]

That doesn’t sound good! What that off the shelf OSM data or smth custom?

[moss-xyz]

This is just an off-the-shelf extract from BBBike.org, dated from around last summer - happy to share the PBF if it helps!

[nilsnolde]

na, it's fine, we don't need an extract. but please do provide a route query against the current OSM valhalla server so we can reproduce.

[moss-xyz]

Does it have to be a route query? It's actually failing at the locate endpoint it seems, a sample query is:
locate?json={"verbose": false, "locations": [{"lat": 33.81422982405634, "lon": -84.39204006270624}], "costing": "bicycle"}

Not sure what you mean by "the current OSM valhalla server", but I'd be curious if the list I provided^ ends up working on a different valhalla instance, if it just happens to be an issue with the graph I built somehow

[dnesbitt61]

DirectedEdge index out of bounds almost always means bad data or issues with building tiles. I ran your locate request above against my local server and it works fine (as did many random requests and bicycle routes I've tried).

[moss-xyz]

Ah well, I suppose that leads to the next questions:

• If this is just a vanilla extract of OSM, why is this happening, and how do I fix this for future extracts?
• Why does changing the min and max_road_class sometimes fix the problem for a given location?

Not sure if you have an easy answer ready, but I'm at least curious!

[kevinkreiser]

the exception shouldn't happen even if its an extract of a larger tileset. if the data is good then we should protect against the case where its missing some of the tiles. its totally possible the locate serializer is missing a case when the data isnt complete. the thing @nilsnolde was say ing above is that we should send the request to the open server: https://github.com/valhalla/valhalla?tab=readme-ov-file#demo-server to see if it fails on this particular area of OSM or if its specific to your build of the tiles.