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.
ors/v2/status
{"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:
{"locations":[[-1.058902,53.549677]],"range":[120,240,360,480,600]}
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:
Where:
- 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?
