5

I am trying to represent isochrones from a points layer using ORS Tools in QGIS 3.8.3-Zanzibar.

Does anyone know why there are some gaps in the resulting polygons, even though the road, according to the OpenStreetMap base layer underneath, is continuous? (OpenRouteService works with OpenStreetMap, so the same network should be used to build the isochrones, right?)

I am especially concerned about the highways and main roads.

Here are some examples:

Secondary roads isochrone polygon gaps

Highway isochrone polygon gaps

Isochrone taking into account vertices

The parameters I used in the ORS Tool were (after obtaining and input the API key):

  • Isochrones from layer option

  • Provider = openrouteservice

  • Input point layer= a layer with 12 points (not very complicated as to see the outputs easily)

  • Travel mode= driving-car

  • Dimension = time

  • Ranges in minutes = 15,30,45,60

If, as the last image shows, the polygons are created following vertices and not just the polylines of the road, how could I densify (as suggested in an answer) the network ORS uses?

Improve this question
1
  • One explanation could be bad OSM source data like tag for speed missing or wrong or in the wrong unit (mile per hour vs km per hour),or if some speed limit are missing it's possible that the tool revert to a default value or wont use this segment for calculation (you need to check with the ORS service to see how it's handled). Another possibility is that the ORS tool use an older/newer copy of the OSM data than the one you are using as basemap.
    – J.R
    Jan 20, 2021 at 15:28

2 Answers 2

Reset to default
4

Such "gaps" can result if you are approaching form two different sides on the network. With your distance/travel time defined, you reach until a certain point, not farther - and this from both sides. There remains a rest "unreachable" in the defined time/distance.

Depending on where your start point is, at least two of the three "gaps" seem to make sense to me. The clearest example is your second screenshot. There are two possible routes that reach the area where your gap starts: it bifurcates at the crossroads marked with red circle. The result makes sense if you choose not distance, but travel time as cost factor. So based on the information of the underlaying network data (speed), the result suggestst that form the crossroads, it takes the same amount of time to reach the sout-eastern end of the gap via route 1 as to reacht the other, north western end of the gap using route 2:

enter image description here

Same case I suppose for the left gap on the first screenshot: you apporoach it from two different sides. The gap on the right side (highway) is more strange, however. Without knowing more about your settings, it's difficult to assess. Does the algorithm really use OpenStreetMap data?

To get different results, you might also try QNEAT3-Plugin. To use it, you need a network (line) layer. You can download OpenStreetMap data with QuickOSM plugin, downloading tag highway (value can remain empty to get all streets). It allows setting shortest (distance) and fastest (time) setting to create isochrones:

enter image description here

Also consider that the very concept of iso-areas is based on interpolation, thus depending on the algorithm used, the result can vary, see: https://gis.stackexchange.com/a/384424/88814

Improve this answer
5
  • Thanks for the answer, but how can route 2 (from your example) be faster than route 1 from the intersection? Route 1 travels on a highway and nº 2 goes through secondary roads.
    – Pescariz
    Jan 20, 2021 at 13:55
  • I do not have the underlaying data, what kind of speed data you have there (and how the tool behaves when data is missing) and I don't know exactly how the routes are calculated. Maybe already at the starting point, route 2 takes another route (going in SW direction, than NW) and thus is faster because route 1 for a long time is stuck in "city traffic"? Without inspecting data and algorithms, it's almost impossible to say.
    – Babel
    Jan 20, 2021 at 14:02
  • You did not accidentally choose "pedestrian" or "bicylce" for the routing? Some roads may be inaccessible for these (or other) reasons...
    – Babel
    Jan 20, 2021 at 14:05
  • No, I chose driving-car. I edited my question to explain further. Unfortunately, I don't know exactly how the routes are calculated, there are few options one can change in the tool, and even if I could have access to data and algorithms I would probably not understand them.
    – Pescariz
    Jan 20, 2021 at 14:18
  • Yes I also tried QNEAT3 with my own road network, but it is not detailed enough (I am working in a whole country), so the results are not acceptable. If I end up having to download the network from OpenStreetMap, I thought I would encounter the same gaps as if doing it right from OpenRouteService.
    – Pescariz
    Jan 20, 2021 at 15:00
3

Could also be down to what is being routed to. I suspect ORS is routing to vertices. So if it is a straight road then it might not route to the location because there are no vertices to rout to. You could try densifying the network first, so adding more points.

Improve this answer
1
  • you could be right: checked the vertices in this section of the highway where the gap at the right in the first screeenshot is: indeed, at least on the right lane (of totally 4, therer are two lanes per direction), there is no vertex where the gap is, see this screenshot with vertex 1 and the next one, no. 2: i.stack.imgur.com/ANZbP.png. However, the connection bypassing this gap still remains strange: OpenStreetMap does not have any connecting road there (blue line).
    – Babel
    Jan 20, 2021 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.