OD Matrix from Layers as Lines (m:n) always reports NULL

[jecogeo]

I'm experiencing an issue that i'm really not sure whether is related to #24. That's why I'm opennig a new issue.

I'm attaching sample_data.zip for verification.

• comuni_utm.shp are de origins
• cidades_utm.shp are the destinations
• hidrosheds_utm_splitted2.shp is the network

My input parameters are as follows:

Input parameters:
{ 'DEFAULT_DIRECTION' : 2, 'DEFAULT_SPEED' : 5, 'DIRECTION_FIELD' : '', 'ENTRY_COST_CALCULATION_METHOD' : 1, 'FROM_ID_FIELD' : 'Localidade', 'FROM_POINT_LAYER' : '/[...]/comuni_utm.shp', 'INPUT' : '/[...]/hidrosheds_utm_splitted2.shp', 'OUTPUT' : 'TEMPORARY_OUTPUT', 'SPEED_FIELD' : '', 'STRATEGY' : 0, 'TOLERANCE' : 50, 'TO_ID_FIELD' : 'NOMEMUNIC', 'TO_POINT_LAYER' : '[...]/cidades_utm.shp', 'VALUE_BACKWARD' : '', 'VALUE_BOTH' : '', 'VALUE_FORWARD' : '' }

The algorithm runs well and output's columns are:

• origin_id (ok)
• destination_id (ok)
• entry_cost (all NULL)
• network_cost (all NULL)
• exit_cost (all NULL)
• total_cost (all NULL)

The result I'm expecting is a table with the distance from all origin points to all destination points through the network. But I'm not sure if I'm correctly understanding the outputs, because all columns of the resulting table refer to a "cost", even if I'm not considering any cost in the network. And I cant see any distance.

[root676]

I tested the algorithms with your datasets - thanks for providing them. There seems to be an issue with the graph as even the shortest path cannot find a way through the network. This is often due to topology problems (eg. edges of the network that are not connected). You can deal with those by altering the tolerance level (which I saw you did). Otherwise check the connectivity of your network manually. Regarding the "cost" issue: Cost is a standard term in graph analysis and refers to the amount of cost/spatial friction/distance that is associated with each edge (can be time cost, money, distance, calories, etc.). In your case - when choosing the distance strategy - the cost column in the result table refers to distance.

[jecogeo]

Hi @root676. Sorry for taking so long to get back to you. As you pointed out errors in my network, I spent a whole day checking it with the Geometry Checker tool. I confirmed 500+ error and manually corrected it using snap to vertex and properly connecting the network to make sure the topology is ok. Even after these corrections, I verified errors in the network still persist, but errors in the order of centimeters.

After testing the tool again, I confirm now the table is populated. But still, an unexpected behavior persists. I'm attaching the results with two different tolerances (50 and 100). I'm considering these values are in map units by default, which is meters (CRS 32720)in this case.

As you can see, not all origins points are connected/measured. Also, some of those points are in the results, but with wrong dummy values. Check, for example, the point ID 68 (in both output_od_matrix_50 and output_od_matrix_100 attached). It has unreal values of distances and equal for all three destination points. Besides this, it seems that doubling the tolerance does not make any effect.

However, the qgis core tool Shortest path (point to point) is able to correctly draw the correct distance with the same tolerance (50). That's why I'm thinking the OD Matrix tool from QNEAT3 is not working as expected. What do you think?

(please find attached the corrected network (net), the two outputs with 50 and 100 of tolerance and the results from Shortest path (point to point) qgis core tool for sample points not processed by QNEAT3 but successfully done it) results.zip

[jecogeo]

Sorry @root676 if I'm pushing, but did you had time to take a look?

[DiegoAlatorre316]

Hola, @jecogeo intentaré escribir en inglés aunque sea bastante malo para ello. Perdón por las faltas gramaticales. Casi no sé inglés y soy nuevo en el mundo de QGIS y la programación.

Do you tried setting layer's CRS system? I had same problem and modifying coordinate system I solved it.

I working in UTM 14N zone. The layer that have destiny points had WGS 84 setting. Whit this setting (UTM 14 N/WGS84) both layers are display no problem in QGIS 3.10.2. But when I run QNEAT3 the columns of the output table are NULL.

Verify that both layers have the same CRS setting.

1. Choose CRS setting of one layer.
2. Save as new archive the other layer, and configure his CRS.
3. Run QNEAT3 whit this new layer and the firsth layer.

Tutorial (in Spanish) to modify the CRS of the layer: https://www.qgistutorials.com/es/docs/working_with_projections.html

I hope it can be useful. Good luck!

[jecogeo]

Do you tried setting layer's CRS system? I had same problem and modifying coordinate system I solved it.

Hi @DiegoAlatorre316 , Thanks for your reply. I tried several different CRS. I would like the problem was that, it would be simpler to solve. If you have the time, could you please test if you manage to run QNEAT3 AND QGIS core tools Shortest path with my dataset (links provided above)?

@root676, I hope you and your familiy are doing well. In times of COVID-19 I really begin worrying when people stop responding.

[root676]

@jecogeo Hi, sorry for the late answer but I am really busy right now (don't worry, I am fine :) ). I will have a look as soon as possible.

[root676]

I just had a look at the data. It is a very strange problem which is somehow related to the vector files you sent me. Every single Origin-Destination pair of the OD matrix gets calculated but assinged with wrong endpoint geometries (multiple OD-Pairs reference the same destination point --> they are not visible on the map because they overlay). This might be related to how geometry is appended to the OD-pairs if a point could not be found... As a solution for your case I would propose that you use the native QGIS algorithm Shortest path (point to layer) as a workaround --> you just have 3 start points. It should be easy to run the algorithm 3 times and merge the result. But in my tests, even this algorithm could not reach 2 of the destination points (this is why I think that the problem is still data related).

[jecogeo]

Thanks, @root676. The problem is: this is a test dataset, just for "proofing" the process chain I have to perform. In my original dataset, I have several thousands of origins points and some hundreds of destinations, so that it will be unpractical to do it "by hand". Is your code actually using the QgsGraphAnalyzer exemplified in the Pyqgis Cookbook? Because it works in my dataset (as shown above).

The problem is I don't have a solution to automate all origins to all destinations. The GUI version of those tools is point (grabbed from the map) to layer (all points of this layer) or vice-versa. Not m:n. I even added a bounty in GIS StackExchange for that.

However if your tool, which is really great, works for me it will be fantastic.

[root676]

I see, so the problem is bigger than the data you sent me... Actually, this is the thing that confuses me: QNEAT3 and the native QGIS algorithms use exactly the same QGIS C++ API in the background. 90% of the "routing magic" is performed by QGIS C++ classes. I also doubt that the problem is related to different tolerance values... Did you manage to implement a script using the PyQGIS cookbook?

[jecogeo]

Did you manage to implement a script using the PyQGIS cookbook?

Unfortunately not... My python skills are not enough yet. If I spend a month on that, I'll certainly succeed. But I've decided to open a bountied question in GIS SE to see if someone can help to speed up the process. I know your tool does exactly what I need, so what cames first is welcomed.

[root676]

I found the error! - here is the result: The error was caused by a missing argument in QgsGraphBuilder - to be precise: the tolerance parameter was never wired with any QNEAT3 graph parameters. Thank you for raising this issue - I will publish a patch for QNEAT3 in the next days. I will provide you with the solution in the gis.stackexchange post - you just have to add the arguments in a specific file.

[jecogeo]

@root676 That's great, great news!! From the very beginning, I thought something was not right with the tolerances. This is really great. I'm glad my problem helped to improve your tool and glad to have a solution to my problem as well. Thanks a lot for your kindness and patience on this thread. And, of course, your reply in GIS SE is very welcome and will be rewarded if definitive!

Please let me know when the patch is available.

[root676]

I just posted the solution in the related question. In 10 minutes you should be good to go with your analysis. Thank you very much for reporting this bug and reminding me to look into it. This really improves the tool!