When running the pollination model using the farms map, I got the following error:
2024-05-06 14:44:17,923 (natcap.invest.utils) utils.prepare_workspace(166) ERROR Exception while executing natcap.invest.pollination
Traceback (most recent call last):
File “natcap\invest\utils.py”, line 164, in prepare_workspace
File “invest\cli.py”, line 470, in main
File “natcap\invest\pollination.py”, line 536, in execute
File “taskgraph\Task.py”, line 336, in init
File “retrying.py”, line 49, in wrapped_f
File “retrying.py”, line 212, in call
File “retrying.py”, line 247, in get
File “six.py”, line 719, in reraise
File “retrying.py”, line 200, in call
File “taskgraph\Task.py”, line 1561, in _execute_sqlite
sqlite3.OperationalError: invalid uri authority: ags-fs-profiles
2024-05-06 14:44:17,945 (natcap.invest.utils) utils.prepare_workspace(169) INFO Elapsed time: 5m 16.980000000000018s
2024-05-06 14:44:17,952 (natcap.invest.utils) utils.prepare_workspace(172) INFO Execution finished InVEST-natcap.invest.pollination-log-2024-05-06–14_39_00.txt (20.2 KB)
Well that is an interesting and unusual error! Thanks for including your logfile.
Based on the parameters logged, it appears that you have your workspace in a network drive. This is very likely the cause of the database locked errors as well. To make sure that this is the issue, could you set your workspace to somewhere on your local computer (somewhere you have write permissions) and try re-running the model? You can always copy the workspace over to your network drive later if you prefer.
Dear James
Thanks very much for your reply. Yes indeed I was aware that my error is probably linked to the virtual IT machine. I already sent a message to the my institute’s IT service. However, InVEST worked now for months using the same workspace. Additionally I reinstalled InVEST on the desktop of the virtual machine. Nevertheless, InVEST is working fine on my private computer. I assume that
the institute now blocked the InVEST app.
Kind regards
Sibylle
Hello James
Yes I reinstalled InVEST on different locations including desktop of the virtual machine. However, at the Desktop version I was not able to open InVEST.
To confirm: is the logfile linked above (which has lots of errors in it and then finally an exception) from the desktop installation on the VM?
Could you attach a logfile from when InVEST ran successfully (or at least did not exhibit this same behavior) when you were using a different workspace location?
Dear James
Find enclosed the log file used some weeks ago with the same InVEST installation at the same place of the virtual machine: AppData_Roaming
So yes hte first log file is on the AppData/Roaming place of the virtual machine.
Dear James
Thank you very much for your feedback. I have been able to report the error with the InVEST app to my department’s IT helpdesk.
Yes, it is definitely a problem with the authorisation. I am not allowed to install any apps or programmes on the personal desktop or on the virtual computer. Unfortunately, the app was probably blocked later. It is still strange, that the app was running for months.
The (inefficient) solution is now to run InVEST on my personal computer and then transfer the output to the storage place at my working location…
In the meantime I received a dedicated (personal) virtual machine from the IT service of my research institution. I successfully installed InVEST and it seems that my test run is without any significant warnings.
However, at the beginning of the log file there is a warning I have not seen before.
Oh, awesome! I’m glad they were able to set you up with a dedicated VM for your work, Sibylle.
2024-07-31 08:54:32,858 (py.warnings) warnings._showwarnmsg(110) WARNING osgeo\gdal.py:312: FutureWarning: Neither gdal.UseExceptions() nor gdal.DontUseExceptions() has been explicitly called. In GDAL 4.0, exceptions will be enabled by default.
I assume this is the warning you’re wondering about? If so, you’re right, this has been a relatively new warning that has cropped up in GDAL, a key library that InVEST uses to read and write many spatial data formats. The FutureWarning indicates that in a future version of GDAL, the default error handling behavior will change, which will change the behavior of many different programs (including InVEST) that use GDAL. There’s nothing that you need to worry about here, since this is a change that we are in the process of making to InVEST and our other libraries.
To be a little more specific about the change, GDAL’s python bindings have historically used C-style errors to indicate that there was a problem. That is, if there was a problem with, say, opening a raster, GDAL would return either None or an error code. This is inconsistent with how most python libraries deal with errors, which is to raise an Exception. Starting in GDAL 4.0, the python bindings will raise exceptions by default, and the developers are kindly giving us plenty of notice before this change goes into effect.