Raster Window Out of Range

[maulanapajie]

Dear Community,

I am getting the following error:
2023-11-17 17:33:42,781 (osgeo) utils._log_gdal_errors(97) ERROR [errno 5] C:\Users\ge59xoj\Documents\ArcGIS\Projects\231115_InVEST\Output_NDR\intermediate_outputs\crit_len_n_Output_NDR_231115_t0.tif, band 1: Access window out of range in RasterIO(). Requested(42496,-28159) of size 256x256 on raster of 76821x34433.

I am using the InVEST 3.13.0 Workbench. Attached you will find my Lognote.

Do you know why this error occurs?

Best,

Maulana

Lognote:
InVEST-natcap.invest.ndr.ndr-log-2023-11-17–15_07_04.txt.zip (210.9 KB)

[dave]

Hi @maulanapajie , thanks for bringing this to our attention. It sounds fairly similar to the bug described here:

SDR and probably other routed models have int32 limitations

Would you mind trying this development build of invest to see if that solves the problem?
https://storage.googleapis.com/releases.naturalcapitalproject.org/invest/3.14.0.post155+g49990e06d/workbench/invest_3.14.0.post155+g49990e06d_workbench_win32_x64.exe

Thank you,

[maulanapajie]

Hi @dave,

Thanks for your reply! At the end my model worked. It turns out it was important to fill the DEM first, before projecting it to the common projected coordinate system that is also used by the other rasters in the NDR model. Before, I projected the DEM first before filling it, thinking that it would make no difference what comes first.

However, I know have encountered some problems with my SDR model that basically uses all the same inputs as the NDR model. The error encountered seemed similar to the github link shared. Do you think this is the case?

I have attached the logfile. Since the only difference between SDR and NDR are the erosivitiy and erodibility rasters representing the K and R factors, I have attached them as well. My guess is that the problem stems from these two rasters.

Thanks again for all your help.

Best,

Maulana

error.zip (6.5 MB)

[dave]

Hi @maulanapajie , I’m glad to hear NDR is working for you.

@maulanapajie

It turns out it was important to fill the DEM first, before projecting it to the common projected coordinate system that is also used by the other rasters in the NDR model. Before, I projected the DEM first before filling it, thinking that it would make no difference what comes first.

I also don’t think the order of these operations should make much difference with respect to this error, though doing the filling in the native coordinate system and saving the projection for last seems prudent. Perhaps the DEM’s datatype was inadvertently changed to an int32 (or lesser) type during one of these operations? That would also avoid the problem.

@maulanapajie

However, I know have encountered some problems with my SDR model that basically uses all the same inputs as the NDR model. The error encountered seemed similar to the github link shared. Do you think this is the case?

I don’t see any errors in the logfile you attached. There are lots of warnings, but those are perfectly safe to ignore. (see also: Fields not successfully written due to large number with respect to field width)

If you do encounter an error similar to the one in your original logfile and detailed in the github link, then please try out our latest build of invest which we think has fixed that bug: https://storage.googleapis.com/releases.naturalcapitalproject.org/invest/3.14.0.post155+g49990e06d/workbench/invest_3.14.0.post155+g49990e06d_workbench_win32_x64.exe

Thank you,