Unable to build subset of foot-walking Isochrone requests

Hi there,

I’ve installed a local instance of ORS using docker for the purpose of requesting a large number of foot-walking travel time isochrones.


{"languages":["cs","cs-cz","de","de-de","en","en-us","eo","eo-eo","es","es-es","fr","fr-fr","gr","gr-gr","he","he-il","hu","hu-hu","id","id-id","it","it-it","ja","ja-jp","ne","ne-np","nl","nl-nl","pl","pl-pl","pt","pt-pt","ro","ro-ro","ru","ru-ru","tr","tr-tr","zh","zh-cn"],"engine":{"build_date":"2023-06-13T12:36:00Z","version":"7.1.0"},"profiles":{"profile 1":{"storages":{"HillIndex":{"gh_profile":"pedestrian_ors_fastest"},"WayCategory":{"gh_profile":"pedestrian_ors_fastest"},"WaySurfaceType":{"gh_profile":"pedestrian_ors_fastest"},"TrailDifficulty":{"gh_profile":"pedestrian_ors_fastest"}},"profiles":"foot-walking","creation_date":"","limits":{"maximum_distance":100000,"maximum_waypoints":50,"maximum_distance_dynamic_weights":100000,"maximum_distance_avoid_areas":100000}}},"services":["routing","isochrones","matrix","mapmatching"]}

This has been done for research. Specifically, I am looking to request travel time isochrones from every Output Area for the UK.

Potentially not a usual issue topic as I have been able to successfully request travel time isochrones for roughly 99.4% of OA’s within the UK.

This post is addressing the failed requests, the distribution of which is shown below. (Don’t think it’s an issue with osm.pbf, they’re nicely spread.)

All errors are identical, returning a 500 status code and 3099 API error code, an unknown internal error

{"error":{"code":3099,"message":"Unable to build an isochrone map."},"info":{"engine":{"build_date":"2023-06-13T12:36:00Z","version":"7.1.0"},"timestamp":1691502194318}}

Most failures seem to make sense. That is, the OA centroid is too far away from any relevant network. I.e,

request body:

I should note that the public facing ORS instance agrees with my local install for the above example:

Other failures I am assuming are due to access restrictions within the OSM network. I.e, I believe, but cannot be sure, that these requests are failing as they are trapped by the surrounding restricting gates. I am not sure if this is expected behaviour, or if an isochrone should be built up to the point of access restriction (the gates).

Again, the public facing instance agrees with my local install, using the isochrone API playground with request body: {"locations":[[-2.183060, 53.439823]],"range":[120,240,360,480,600]}

View from Bowler St of one of the gates:

Assuming my assumptions above are correct. That is, most are failing due to being far from the network and some are failing due to access restrictions - I cannot find a reasonable excuse for the following examples to fail:


  • Colinsbrough grove: -1.374681, 53.789393
  • Wesley close: -0.599108, 53.656714

Both result in failed API calls:

Though both Colinsbrough grove and Wesley close centroids are technically not on a network, as is the field centroid in the first examples, I am assuming that both Colinsbrough grove and Wesley close should snap to the nearest network and successfully build the Isochrone.

I am aware that foot-walking isochrones do have some issues, and this may be a continuation of this? However, the linked issue in question involved a centroid on a train platform, which I imagine to be more confusing (access, walking on buildings etc.) that right next to a road, as is the case for my two examples above.

I should also note that trying the same coordinates above ( Colinsbrough grove and Wesley close) with car-driving, the snapping occurs as I expect it would for foot-walking, and the isochrone is built:
(snapped locations circled in Blue)

Do foot-walking isochrones currently attempt to snap to the nearest location?


for your cases that are trapped in restricting gates, it might be the case that the corresponding subnetwork is not included in the routing graph due to its size, so the isochrone not building at all would be expected.

For the Conisborough Grove case, I’m guessing the issue is that this was only recently changed from a construction-highway to a regular highway, so I assume the necessary changes haven’t been taken into account yet (see here).

For the Wesley Close case, I’m guessing the issue lies in the small path right of the street.
That path is not connected to the road network, it is rather a “standalone” feature, and I could imagine the point snapping to it and then not being able to build an isochrone. This guess is strengthened by the fact that moving the point to the left of Wesley Close enables it in building an isochrone.

I agree that in this case, snapping probably should snap to something useful, at least for the Wesley Close case. Would you mind opening an issue here?

Best regards

1 Like

Hi @jschnell

Many thanks for your response and answering pretty much all of my questions!

For further clarity - if a part of the network is restricted by access restrictions (say the gated communities in my example, but could be any factory/school area e.t.c) is this removed from the route-able network when the network graph is made? This would make sense as to why a lot of my requests have failed.

Many thanks for the clarification on outdated highway tag - it’s probably best I re-try this with my failed locations in another week or so to see if any OSM updates have affected this.

Finally, thank you for the suggestion RE standalone features not part of route-able networks. I have gone and connected the cursed footpath to the network so this issue shouldn’t happen again, at least not for Wesley Close :slight_smile:

I’ve also created a GH issue on foot-walking requests being snapped to stand alone features - thanks for pointing me in the right direction.

Many thanks

Currently, they are removed from the graph network, yes.

In the future we might have some functionality to allow routing on restricted roads, but currently we don’t have capacity for or a funded project related to this.

1 Like