Qneat3 Plugin

[Othon Sdcd]

QNEAT3is a QGIS plugin that is written in Python and is integrated in the QGIS3 Processing Framework. It offers advanced network analysis algorithms that range from simple shortest path solving to more complex tasks like Isochrone Area (aka service areas, accessibility polygons) and OD-Matrix (Origin-Destination-Matrix)computation.

All algorithms make use of the QGIS3 Python API, especially the graph analysis classes that are written in C++. This lays a positive basis in terms of algorithm performance as the heavy computing (like dijkstra algorithm) is performed using C++ machine code. Other algorithms like polygon and contour based Iso-Area also make use of C/C++ based code like the QGIS Interpolation classes for distance value interpolation, GDAL library for raster data io and numpy for further processing.

In the previous tutorial, Basic Network Visualization and Routing (QGIS3), we learned how to build a network and calculate the shortest path between 2 points. We can apply that technique to many different types of network-based analysis. One such application is to compute Origin-Destination Matrix or OD Matrix. Given a set of origin points and another set of destination points, we can calculate the shortest path between each origin-destination pairs and find out the travel distance/time between them. Such analysis is useful to locate the closest facility to any given point. For example, a logistics company may use this analysis to find the closest warehouse to their customers to optimize delivery routes. Here we use the Distance Matrix algorithm from QGIS Network Analysis Toolbox (QNEAT3) plugin to find the nearest health facility to each address in the city.

We will take 2 layers for Washington DC - one with points representing addresses and another with points representing mental health facilities - and find out the facility with the least travel distance from each address.

Locate the Community_Based_Service_Providers.zip file, expand it and add Community_Based_Service_Providers.shp to the canvas. We will select only those centres providing facilities to adults. Right-click on the Community_Based_Service_Providers.shp layer and select Filter.

Select Address_Points as the Input layer, Number of feature as the Method and, enter 1000 in the Number/percentage of features. In the Extracted (random) choose the ... and click Save to a file. Now choose the directory and enter the name as address_point_subset.shp and click Run.

As the algorithm will extract 1000 random points from the given data set, to replicate the exact points used in this exercise you can download the subset file which we got during the execution of the algorithm here address_point_subset.zip . After downloading load address_point_subset.shp layer into QGIS.

Similarly, rename the Community_Based_Service_Provider layers representing the health facilities as destination_points. Naming the layers this way makes it easy to identify them in subsequent processing. Further we will open processing toolbox to create the distance matrix using origin and destination layers.

This algorithm helps find the distances along with the network between selected origin and destination layers. Select Roadway_Block as the Network layer. Select origin_points as the From-Points layer and OBJECTID as the Unique Point ID field. Similarly, set destination_points as the To-Points Layer and OBJECTID as the Unique Point ID field. Set the Optimization Criterion as Shortest Path (distance optimization).

As many streets in the network are one-way, we need to set the Advanced parameters to specify the direction. See Basic Network Visualization and Routing (QGIS3) for more details on how these attributes are structured. We also have an option to select geometry style of the generated matrix. We are having a road network with direction information so we can generate matrix by folling the route. Choose Matrix geometry follows routes. Choose SUMMARYDIR as the Direction field. Enter OB as the Value for the forward direction, IB as the Value for backward direction, and BD as the Value for the both direction. Set the Topology tolerance as 0.0000150. Keep other options to their default values and click Run.

A new table layer called Output OD Matrix will be added to the Layers panel. Right-click and select Open Attributes Table. You will see that the table contains 67000 rows. We had 67 origin points and 1000 destination points - so the output contains 67x1000 = 67000 pairs of origins and destination. The total_cost column contains distance in meters between each origin point to every destination point.

In Additional input data sources select ... and check the Output OD Matrix and, click OK. Now click the Summation under SQL query. Enter the following query in SQL query dialog box. Enter geometry as the Geometry field and, select LineString as the Geometry type. Click Run.

To accomplish this I am using the QNEAT3 plugin. It worked very efficiently and I was exceedingly pleased by it. However, upon closer inspection I found that the distance between point A and itself was 50 hours in the network.

I have previously posted this but I've been running into a hard to understand problem using QGIS's QNEAT3 Plugin. I've contacted the creator of the plugin and he was unsure of the problem too. I'm attempting to run it using 10 points generated at random across an entire medium-sized countries worth of historical OSM data, downloaded using OSMIUM. I'm working on a research project that attempts to ascertain if OSM data for entire countries from different years can be used for network routing.

the creator suggested it might have to do with "One possible cause that the QGIS API Documentation gives is:" if snappedPoints[i] == QgsPointXY(0.0,0.0) then snapping failed. I think this is pretty unlikely, as I tried generating the points randomly, and I tried generating them on a buffer so that they are extremely close to the lines within the network. I also notice occasionally, when the graph builds successfully, not all the points are included in the final output.

I am also wondering if some of my OSM country-level data might fail because the entire network is entirely unrouteable. I have noticed that when I test a mini-version with just a single point to point calculation using QGIS's native routing info (Not QNEAT 3), the graph fails on the same layers that fail in the OD Matrix version. However, I would have expected a different set of errors than the one above that communicates this issue.

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 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.

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.

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.

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.

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).

3a8082e126