search

root676 / QNEAT3

QNEAT3 - Qgis Network Analysis Toolbox 3
GNU General Public License v3.0
63 stars 12 forks source link

tools that use calcIsoPolygons fail #60

Closed chrisbnyc closed 1 year ago

chrisbnyc commented 1 year ago

Hello, I tried using QNEAT on both QGIS 3.28.3 and 3.22 LTR and while the tools for generating point clouds work as expected, any tool that uses the calcIsoPolygons function fail.

Here is a sample trace I could get from the processing parameters dialog in 3.28:

Traceback (most recent call last): File "/Users/x/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins/QNEAT3/algs/IsoAreaAsPolygonsFromLayer.py", line 255, in processAlgorithm polygon_featurelist = net.calcIsoPolygons(max_dist, interval, output_path) File "/Users/x/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins/QNEAT3/Qneat3Framework.py", line 470, in calcIsoPolygons band_in = ds_in.GetRasterBand(1) AttributeError: 'NoneType' object has no attribute 'GetRasterBand'

This was on Mac OS 12.6.2 which has Python 3.9.12 and a plain install of QGIS.

Is there any other information I can provide that would help debug this?

chrisbnyc commented 1 year ago

This also appears to give the same error on Windows 11 - same versions (3.28.3).

chrisbnyc commented 1 year ago

FWIW on the Mac I was able to get this more specific error when I tried specifying an output file instead of a temporary layer:

ds_in = gdal.Open('/Users/x/Documents/test_output.tif') File "/Applications/QGIS.app/Contents/MacOS/lib/python3.9/site-packages/GDAL-3.3.2-py3.9-macosx-10.13.0-x86_64.egg/osgeo/gdal.py", line 4473, in Open return _gdal.Open(*args) RuntimeError: Invalid dataset dimensions : 0 x 0

The file did not exist and QGIS has access to my Documents directory so accessing an existing file should not be a problem.

josephholler commented 1 year ago

I used to see an error like this if any of the iso areas were just a point or a straight line, such that a valid 2d "polygon" could not be drawn. I observed this on a testing dataset for which my distance was short enough to fall within a precisely straight line segment. It could easily happen in real data if, e.g. an origin point snapped to an isolated line segment with no connectivity to other parts of the network.

On Fri, Feb 3, 2023, 11:22 PM Christopher Barnes @.***> wrote:

FWIW on the Mac I was able to get this more specific error when I tried specifying an output file instead of a temporary layer:

ds_in = gdal.Open('/Users/x/Documents/test_output.tif') File "/Applications/QGIS.app/Contents/MacOS/lib/python3.9/site-packages/GDAL-3.3.2-py3.9-macosx-10.13.0-x86_64.egg/osgeo/gdal.py", line 4473, in Open return _gdal.Open(*args) RuntimeError: Invalid dataset dimensions : 0 x 0

The file did not exist and QGIS has access to my Documents directory so accessing an existing file should not be a problem.

— Reply to this email directly, view it on GitHub https://github.com/root676/QNEAT3/issues/60#issuecomment-1416656788, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMTA72YN6HWLLBTCHH2DKLWVXKRLANCNFSM6AAAAAAUQK5WMU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

root676 commented 1 year ago

@josephholler is totally right. Another cause for the error could be a faulty cell size (eg. one so big, the distance raster cannot be drawn in a meaningful way). But usually the error occurs when the pointcloud could not be generated or is empty (eg. see comment of @josephholler).

chrisbnyc commented 1 year ago

Thanks, it was the cell size issue - caused by user confusion. My assumption that changing the CRS of the line file to UTM 11N was making the file valid was incorrect. Once I used ogr2ogr to ensure the geojson was EPSG:3741 when I loaded the layer it worked fine.

So this not a QNEAT issue as much as a QGIS (or probably any GIS system) issue where projections and transforms are a little too opaque to the user. Thanks for the quick reply!