Various failures in QGIS 3.12

[atlight]

The data is in this GeoPackage:
IC plugin bug.zip

Albury dataset

Note: this dataset should be in MGA Zone 55. Reproject the data to EPSG:28355 before trying.

Blocks layer: Albury blocks - reprojected temporary layer
Dead-end removal: NO
Starting point layer; Albury startingpoint - reprojected temporary layer
Max walking distance: 200 m
--> succeeds

Blocks layer: Albury blocks - reprojected temporary layer
Dead-end removal: YES, 40 m
Starting point layer: Albury startingpoint - reprojected temporary layer
Max walking distance: 200 m
--> fails with following error:

Traceback (most recent call last):
  File "C:/Users/.../AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\interfacecatchment\interface_catchment.py", line 904, in execute
    'FIELD_PRECISION' : 1,
  File "C:/PROGRA~1/QGIS3~1.12/apps/qgis/./python/plugins\processing\tools\general.py", line 106, in run
    return Processing.runAlgorithm(algOrName, parameters, onFinish, feedback, context)
  File "C:/PROGRA~1/QGIS3~1.12/apps/qgis/./python/plugins\processing\core\Processing.py", line 181, in runAlgorithm
    raise QgsProcessingException(msg)
_core.QgsProcessingException: There were errors executing the algorithm.

Blocks layer: Albury blocks - reprojected temporary layer
Dead-end removal: YES, 40 m
Starting point layer: Albury startingpoint - reprojected temporary layer
Max walking distance: 280 m
--> QGIS hangs

Carlton dataset

Blocks layer: Carlton blocks
Dead-end removal: NO
Starting point layer; Carlton startingpoint
Max walking distance: 200 m
--> succeeds

Blocks layer: Carlton blocks
Dead-end removal: YES, 40 m
Starting point layer; Carlton startingpoint
Max walking distance: 250 m
--> succeeds

Blocks layer: Carlton blocks
Dead-end removal: YES, 40 m
Starting point layer; Carlton startingpoint
Max walking distance: 200 m
--> fails with following error:

Traceback (most recent call last):
              File "C:/Users/.../AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\interfacecatchment\interface_catchment.py", line 908, in execute
              IC = round(next(walkable_lines_layer.getFeatures())['IC'])
             TypeError: type QVariant doesn't define __round__ method

Blocks layer: Carlton blocks
Dead-end removal: YES, 40 m
Starting point layer; Carlton startingpoint
Max walking distance: 400 m
--> QGIS hangs

Version info

Python version: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] 
QGIS version: 3.12.3-București București, 8234261527 

[atlight]

@imajic-unimelb wondering if you could look into this in the next few weeks? We'd like to use this plugin for teaching in Semester 2.

[ivan-majic]

Hi @atlight , thank you for reporting these issues and documenting them nicely. I am planning to investigate these soon, certainly before the start of Semester 2.

[ivan-majic]

Hi @atlight , thank you again for noticing and raising these issues and for your patience.
I have now made some changes to address the issues and all the cases work fine for me now.

Albury dataset

The issues, in this case, were caused by the unexpected format of the input blocks layer. You have used land parcel data and I had not anticipated that before. I would expect that all polygons would represent single building blocks, meaning that touching land parcels in your case would be dissolved (please see the attached GeoPackage for example). I have now added a few steps that take care of cases where input polygons are touching each other and then proceed with IC calculation.

Carlton dataset

There was an issue with one of the processing algorithms I use in IC calculation when calculating "sum($length)" for all of the resulting IC lines. This seems to be a known bug (https://gis.stackexchange.com/questions/299577/qgis-sum-line-lengths-return-nan) and in your case #2 the length of one line was always calculated as "nan" which failed the rest of the plugin. This is fixed now.

For the case #3, I did not find any issues but it just took quite long to calculate IC for 400 m walking radius (approx. 35 minutes). What I have noticed with your input blocks for Carlton is that you have many vertices in your geometries that seem unnecessary.
In other words, straight (or almost straight) block edges are represented with more than 2 points. The IC algorithm analyses visibility between all pairs of relevant block vertices and is very sensitive to such "dirty" geometries. An easy way to solve this is to "clean" the block vertices by using the Vector -> Geometry Tools -> Simplify algorithm. I usually use Douglas-Peucker method with 0.1 m tolerance. I have put the simplified Carlton blocks layer in the attached GeoPackage as well, but here is the comparison of IC performance for original and simplified Carlton blocks:
Original-Carlton-blocks: 9 iterations, IC=13808 m, runtime=2104.58 seconds
Simplified-Carlton-blocks: 9 iterations, IC=13805 m, runtime=128.26 seconds

Attachment atlight_IC_blocks.zip

Plugin update

I have submitted the updated version of the plugin to QGIS repository, but it might be a few days until it is reviewed. Once it goes through, you will be able to upgrade to version 1.3 where these fixes are implemented.

P.S. I have noticed you reproject the blocks and the starting point layers before running IC. The plugin itself reprojects both layers into the current project CRS. I might have to add a note for that in the UI to make people aware but just wanted to let you know that it is already done behind the scenes.

[atlight]

Thanks for looking into the issues and for the detailed analysis. If I recall correctly, the parcel data was taken more or less directly from the respective State Government spatial data services, so I am not too sure what is going on with the vertices etc.

It didn't occur to me to dissolve the blocks before use - thank you for incorporating a step to do this. I believe the AwaP plugin already included this step, so it is good that there is now consistency across the two tools.

I will keep in mind your comment about simplification as well. That sounds like a useful preparatory step for geometrically messy parcel data.

Once again I really appreciate your work to look into this!