Nature Access TypeError: int() argument must be a string

Software Support
1

What is the issue or question you have?

I continue to get basic errors when trying to run the Nature Access Model. I am using an urban green space raster clipped to the extent of Los Angeles City. There are five land use attributes 0-4 (Zero is no urban nature, 1-4 is urban nature of different types), where lu attributes 2-4 have a nature access value of 1, and all others have zero. I am using the same search distance for all attributes.
The population raster is from the EPA Dasymetric population data, also clipped to LA, and the administrative boundary is the city boundaries of Los Angeles.

What do you expect to happen?

I expect it to run and provide me the nature supply and demand outputs

What have you tried so far?

I have ran the model using a similar LU raster, but with only 4 attributes, excluding the zero-data attribute for no-data

Attach the logfile here:

05/02/2023 14:18:05 natcap.invest.urban_nature_access INFO Starting Urban Nature Access Model
05/02/2023 14:18:05 natcap.invest.urban_nature_access INFO Using decay function dichotomy
05/02/2023 14:18:05 pygeoprocessing.geoprocessing INFO starting stats_worker
05/02/2023 14:18:05 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-1 (stats_worker), started daemon 14480)>
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO 100.0% complete
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO Waiting for raster stats worker result.
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO starting stats_worker
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-2 (stats_worker), started daemon 15140)>
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO 100.0% complete
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO Waiting for raster stats worker result.
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO starting stats_worker
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-3 (stats_worker), started daemon 10856)>
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO 100.0% complete
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO Waiting for raster stats worker result.
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO starting stats_worker
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-4 (stats_worker), started daemon 12516)>
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO 100.0% complete
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO Waiting for raster stats worker result.
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO starting stats_worker
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-5 (stats_worker), started daemon 2016)>
05/02/2023 14:18:06 pygeoprocessing.geoprocessing ERROR exception encountered in raster_calculator
Traceback (most recent call last):
File “pygeoprocessing\geoprocessing.py”, line 517, in raster_calculator
File “natcap\invest\urban_nature_access.py”, line 2612, in _mask
TypeError: int() argument must be a string, a bytes-like object or a real number, not ‘NoneType’
05/02/2023 14:18:06 pygeoprocessing.geoprocessing INFO Waiting for raster stats worker result.
05/02/2023 14:18:06 pygeoprocessing.geoprocessing_core WARNING No valid pixels were received, sending None.
05/02/2023 14:18:06 taskgraph.Task ERROR Something went wrong when adding task Mask lulc to the known valid pixels (4), terminating taskgraph.
Traceback (most recent call last):
File “taskgraph\Task.py”, line 674, in add_task
File “taskgraph\Task.py”, line 1093, in _call
File “natcap\invest\urban_nature_access.py”, line 2615, in _mask_raster
File “pygeoprocessing\geoprocessing.py”, line 517, in raster_calculator
File “natcap\invest\urban_nature_access.py”, line 2612, in _mask
TypeError: int() argument must be a string, a bytes-like object or a real number, not ‘NoneType’
05/02/2023 14:18:06 natcap.invest.utils ERROR Exception while executing natcap.invest.urban_nature_access
Traceback (most recent call last):
File “natcap\invest\utils.py”, line 164, in prepare_workspace
File “invest\cli.py”, line 469, in main
File “natcap\invest\urban_nature_access.py”, line 781, in execute
File “taskgraph\Task.py”, line 674, in add_task
File “taskgraph\Task.py”, line 1093, in _call
File “natcap\invest\urban_nature_access.py”, line 2615, in _mask_raster
File “pygeoprocessing\geoprocessing.py”, line 517, in raster_calculator
File “natcap\invest\urban_nature_access.py”, line 2612, in _mask
TypeError: int() argument must be a string, a bytes-like object or a real number, not ‘NoneType’
05/02/2023 14:18:06 natcap.invest.utils INFO Elapsed time: 0.43s
05/02/2023 14:18:06 natcap.invest.utils INF

2

Welcome to the forum @Pibsen!

In general, when posting about an error, please upload the entire log file, which has additional information (like a listing of your inputs) that could help us troubleshoot.

This error message isn’t very helpful, and since this is a new model I don’t have a feel for what might be happening. So could you please package up your inputs and send them to me? The most useful way is like this:

1/ In InVEST Workbench, go to the tab where you’re entering your model inputs.
2/ Click on “Save As…” in the left side of the screen.
3/ In the “Datastack options” window that appears, click on “Parameters and data”.
4/ Give the output file a name (leaving it as the default is fine too), and make sure that the file extension is “.tgz”.
5/ Save the file and send it to me at swolny@stanford.edu.

Thanks!

~ Stacie

3

Thanks for sending your data @Pibsen. I found a few things going on.

The cause of the initial error was because the land use/land cover map does not have a NoData value set. I exported the LULC raster to a new file, added a NoData value, and got past that error.

Then there was another error, due to there being a value of 255 in the LULC raster that is not present in lulc_attribute_table_csv.csv. I added a value of 255 to the CSV (with an urban_nature value of 0) and it fixed that problem.

The last thing I noticed is that the City_Boundary shapefile has the geographic coordinate system WGS84, when it needs to have the same projected coordinate system as your other inputs (as noted in the Data Needs section of the User Guide). It seems to me that Workbench should be catching this when it’s entered into the user interface, since it usually does this kind of error-checking, but it’s not. So you’ll need to reproject the City_Boundary layer to match the others.

Then the model ran successfully. Please let us know if you run into anything else, it’s helpful to get feedback from users about new models.

~ Stacie

4

Thank you! That got the model working :slight_smile:

5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.