By
2019-07-07
QGIS
12 Comments

Five QGIS network analysis toolboxes for routing and isochrones

In the past, network analysis capabilities in QGIS were rather limited or not straight-forward to use. This has changed! In QGIS 3.x, we now have a wide range of network analysis tools, both for use case where you want to use your own network data, as well as use cases where you don’t have access to appropriate data or just prefer to use an existing service.

This blog post aims to provide an overview of the options:

  1. Based on local network data
    1. Default QGIS Processing network analysis tools
    2. QNEAT3 plugin
  2. Based on web services
    1. Hqgis plugin (HERE)
    2. ORS Tools plugin (openrouteservice.org)
    3. TravelTime platform plugin (TravelTime platform)

All five options provide Processing toolbox integration but not at the same level.

If you are a regular reader of this blog, you’re probably also aware of the pgRoutingLayer plugin. However, I’m not including it in this list due to its dependency on PostGIS and its pgRouting extension.

Processing network analysis tools

The default Processing network analysis tools are provided out of the box. They provide functionality to compute least cost paths and service areas (distance or time) based on your own network data. Inputs can be individual points or layers of points:

The service area tools return reachable edges and / or nodes rather than a service area polygon:

QNEAT3 plugin

The QNEAT3 (short for Qgis Network Analysis Toolbox 3) Plugin aims to provide sophisticated QGIS Processing-Toolbox algorithms in the field of network analysis. QNEAT3 is integrated in the QGIS3 Processing Framework. It offers algorithms that range from simple shortest path solving to more complex tasks like Iso-Area (aka service areas, accessibility polygons) and OD-Matrix (Origin-Destination-Matrix) computation.

QNEAT3 is an alternative for use case where you want to use your own network data.

For more details see the QNEAT3 documentation at: https://root676.github.io/index.html

Hqgis plugin

Access the HERE API from inside QGIS using your own HERE-API key. Currently supports Geocoding, Routing, POI-search and isochrone analysis.

Hqgis currently does not expose all its functionality to the Processing toolbox:

Instead, the full set of functionality is provided through the plugin GUI:

This plugin requires a HERE API key.

ORS Tools plugin

ORS Tools provides access to most of the functions of openrouteservice.org, based on OpenStreetMap. The tool set includes routing, isochrones and matrix calculations, either interactive in the map canvas or from point files within the processing framework. Extensive attributes are set for output files, incl. duration, length and start/end locations.

ORS Tools is based on OSM data. However, using this plugin still requires an openrouteservice.org API key.

TravelTime platform plugin

This plugin adds a toolbar and processing algorithms allowing to query the TravelTime platform API directly from QGIS. The TravelTime platform API allows to obtain polygons based on actual travel time using several transport modes rather, allowing for much more accurate results than simple distance calculations.

The TravelTime platform plugin requires a TravelTime platform API key.

For more details see: https://blog.traveltimeplatform.com/isochrone-qgis-plugin-traveltime

12 comments
  1. Sorin RUSU said:

    Hi anita, great in-depth article. I have played with the QGIS plugin before but found it lacking Z-connectivity configuration when you want to add a road network that has features like tunnels and overpasses. Without Z-connectivity the short route algorithm usually shoots right through the tunnel wall to the above street (similar behavior for the overpasses). Is there any configurations possible via some network attributes, or are we simply relegated to the pgRouting and/or ESRI’s network dataset realms? The online ORS/Hqgis do follow Z-level topology, however they do not allow using our own datasets in the algorithms.

    • Which plugin specifically are you referring to? The core network analysis tools? Are you saying that it introduces nodes where bridge/tunnel edges go under/over regular edges, thus introducing fake intersections? If nodes (i.e. edge start/end points) already exist at those problematic locations, the issue may be due to the graph builder logic which only evaluates x/y information. In general, building a graph from edges with start node and end node information is much more reliable than trying to derive it from geometric information alone.

  2. Sorin RUSU said:

    Thanks for the comment – I was referring to the core network analysis tools, however I believe I was partly mistaken. I was under the mistaken belief that if you draw two intersecting lines with a pseudo-node (no true vertex at the intersection point), and specify that as the input in a road network, it will route you from one line to the other (thus having a right turn from a tunnel to the above street). However I re-tested this morning and in order to have it route through intersecting lines, both lines need to ‘share’ a common X/Y vertex (if only one line has a vertex at the intersection point, or if no vertex exists at the intersection point the the short route fails). This means that if tunnels/overpasses are drawn as ‘straight’ lines without sharing a vertex with the roads going above/under, than everything should be golden. However if both bridge/tunnel line shares a vertex with the street below/above, it will route you through the wall/off the bridge. Maybe a picture would be worth a thousand words, however no idea if there’s a way to upload.

  3. Andres said:

    Thanks Anita for your post.
    I was waiting for the possibility to create Origin-Destination Matrix without pgRouting and the QNEAT3 plugin does it in a very efficient way. This allows for an efficient advanced spatial analysis. The only issue I have is that the same Origin-Destination Matrix creation algorithm takes about 10 times longer if I use it within the Graphical Modeler (Processing Modeler).

    Cheers and thanks again

    • That is indeed odd and might be worth to get in contact with the developers to find out what may be going on.

  4. Benedetta said:

    Hi Anita, very interesting post. I would like to know if you are also aware of the state of the art concerning the Travelling Salesman Problem. Thank you!

  5. michele vietri said:

    Hi Anita, this is a very interesting post!! I’m not an expert so I would like to ask you 2 questions. I have installed QGIS and
    1) I would like to define a route starting from a specific GPS point on a specific road giving a certain distance. Then I would like to split this distance (for instance 20 Km from “GPS1” along the “A1” Highway in Italy) into 40 segments, each one after 500 meters. And finally I would like to color them in three different colors. Is it possible? can you explain me how to in QGIS?
    2) I would like also to upload from a csv the data described above to have the same result. How can I do in QGIS? how the CSV format must be?

    May be it is a stupid question or too complex (I don’t know), but thanks anyway!!

    ciao
    Michele

    • michele vietri said:

      HI Anita, please help me :-)

  6. Ron said:

    Thanks Anita, great to have a place where we can get some commentary on this fast(ish) developing capability. Been using pgrouting for a while both in and outside of QGIS but I’ve been wholly unsuccessful in getting anything out of the QNEAT3 plugin with a pgrouting network table I routinely use – QNEAT3 error messages are completely generic/unhelpful. Can’t find any documentation on what it’s accepting re network (though I guess that’s a question for the dev), any hints on on the net side of things?

    • You’re right, the best way to improve documentation is by contacting the developer https://root676.github.io/index.html
      I’m not aware of specific differences / common pitfalls between pgRouting and QNEAT networks.