This forum is shutting down! Please post new discussions at community.naturalcapitalproject.org

Biophysical table error

Hi All,

I'm a new user to the natural capital project and attempting to use the seasonal water yield model. I've run up against some errors that seem to do with my biophysical table. There error message I get is:

ValueError: There was not a value for at least the following codes [ 0.] for this file C:\Users\ptelaroli\Documents\Burney Work\lulc_valid.tif.

Nodata value is: 255.0

 
I'm assuming this is due to a missing value in my biophysical table for a no data value that matches the lulc. That said, when I've tried incorporating the value into my biophysical table it still doesn't run. So, I'm not sure if I'm inputting the correct value(s) into my biophysical table. I'm copying part of the log below. Please let me know if there is any more information that would be helpful.

 Any help or advice would be great! Thanks in advance

-Pete

03/20/2017 10:32:30 natcap.invest.seasonal_water_yield.seasonal_water_yield INFO classify kc

03/20/2017 10:32:30 root ERROR ---------------------------------------------------

03/20/2017 10:32:30 root ERROR ---------------------- ERROR ----------------------

03/20/2017 10:32:30 root ERROR ---------------------------------------------------

03/20/2017 10:32:30 root ERROR Error: exception found while running natcap.invest.seasonal_water_yield.seasonal_water_yield

03/20/2017 10:32:30 root DEBUG

03/20/2017 10:32:30 root DEBUG Build details

03/20/2017 10:32:30 root DEBUG Interpreter

03/20/2017 10:32:30 root DEBUG Current temp dir: C:\Users\ptelaroli\Documents\Burney Work\tmp

03/20/2017 10:32:30 root DEBUG tempfile.tempdir: C:\Users\ptelaroli\Documents\Burney Work\tmp

03/20/2017 10:32:30 root DEBUG

03/20/2017 10:32:30 root DEBUG System

03/20/2017 10:32:30 root DEBUG OS : Windows-8-6.2.9200

03/20/2017 10:32:30 root DEBUG Processor architecture: AMD64

03/20/2017 10:32:30 root DEBUG FS encoding : mbcs

03/20/2017 10:32:30 root DEBUG Preferred encoding: cp1252

03/20/2017 10:32:30 root DEBUG

03/20/2017 10:32:30 root DEBUG Python

03/20/2017 10:32:30 root DEBUG Version : 2.7.9

03/20/2017 10:32:30 root DEBUG Build : ('default', 'Dec 10 2014 12:24:55')

03/20/2017 10:32:30 root DEBUG Compiler : MSC v.1500 32 bit (Intel)

03/20/2017 10:32:30 root DEBUG Implementation : CPython

03/20/2017 10:32:30 root DEBUG Architecture : 32bit

03/20/2017 10:32:30 root DEBUG Linkage format : WindowsPE

03/20/2017 10:32:30 root DEBUG

03/20/2017 10:32:30 root DEBUG Packages

03/20/2017 10:32:30 root DEBUG Cython : ?

03/20/2017 10:32:30 root DEBUG Numpy : 1.11.2rc1

03/20/2017 10:32:30 root DEBUG Scipy : 0.16.1

03/20/2017 10:32:30 root DEBUG OSGEO : 1.11.3

03/20/2017 10:32:30 root DEBUG Shapely : 1.5.5

03/20/2017 10:32:30 root DEBUG InVEST : 3.3.2

03/20/2017 10:32:30 root DEBUG

03/20/2017 10:32:30 root DEBUG

03/20/2017 10:32:30 root DEBUG Exception not environment-related

03/20/2017 10:32:30 root DEBUG Printing traceback

Traceback (most recent call last):

File "C:\Users\natcap-servers\jenkins-home\workspace\natcap.invest\label\GCE-windows-1\exe\build\invest\out00-PYZ.pyz\natcap.invest.iui.executor", line 560, in runModel

File "C:\Users\natcap-servers\jenkins-home\workspace\natcap.invest\label\GCE-windows-1\exe\build\invest\out00-PYZ.pyz\natcap.invest.seasonal_water_yield.seasonal_water_yield", line 163, in execute

File "C:\Users\natcap-servers\jenkins-home\workspace\natcap.invest\label\GCE-windows-1\exe\build\invest\out00-PYZ.pyz\natcap.invest.seasonal_water_yield.seasonal_water_yield", line 419, in _execute

File "C:\Users\natcap-servers\jenkins-home\workspace\natcap.invest\label\GCE-windows-1\exe\build\invest\out00-PYZ.pyz\pygeoprocessing.geoprocessing", line 1620, in reclassify_dataset_uri

File "C:\Users\natcap-servers\jenkins-home\workspace\natcap.invest\label\GCE-windows-1\exe\build\invest\out00-PYZ.pyz\pygeoprocessing.geoprocessing", line 2407, in vectorize_datasets

File "C:\Users\natcap-servers\jenkins-home\workspace\natcap.invest\label\GCE-windows-1\exe\build\invest\out00-PYZ.pyz\pygeoprocessing.geoprocessing", line 1610, in map_dataset_to_value

ValueError: There was not a value for at least the following codes [ 0.] for this file C:\Users\ptelaroli\Documents\Burney Work\lulc_valid.tif.

Nodata value is: 255.0

Comments

  • RichRich Administrator, NatCap Staff
    Hi Pete, it looks like it's specifically a landcover code of 0 that's missing.  You said you incoproprated it into your table but it still "didn't run", do you mean it still had the exact same error?

    Also, just want to make sure you're running the latest version of InVEST, 3.3.3?  We've had some issues in the past with some byte-type rasters and this code but should be fixed now.

    And if none of this is helpful, could you dropbox me your data to richsharp@stanford.edu and I'll try to take a look directly?
  • Hi Rich,

    Thanks for following up - I was able to fix the value issue but am still having problems. The landcover code 0 is a background value associated with the raster (I'm using the NASS LULC raster). I ran it on 3.3.3 and get a variety of error messages depending on what values I put into the biophysical table for the CN ad Kc values for the 0 landcover code. I'll dropbox you the data in a second.

    Thank you - I appreciate the help!

    -Pete
  • RichRich Administrator, NatCap Staff
    Hi Pete, I got your dropbox. I notice the DEM you sent is at a 3.3km cell resolution.  The model uses the DEM to classify streams and route water across the landscape.  In turn, the model aligns and scales all input rasters to the resolution and orientation of the DEM.  In your case it'd destroy all the data precision you have. Aside from that, it'd attempt to classify streams 3.3km wide.  If it ran at all, I'd expect the results to be meaningless.

    The model behaves computationally and numerically better if the input rasters are the same size and resolution.  Any chance you can do that in your case?  Even if you don't want to rescale everything, can you try a DEM with a finer resolution like 90 or 30m?

    Sorry, I know that's a lot of work...

  • Hi Rich,

    Thanks for following up and apologies for the delayed response - I was out of town for a bit. I do believe I can use a finer DEM, most likely from the geospatial data gateway. When this project was started, the gateway was taken offline so we had to look for another DEM. Would the LiDAR elevation data set at 1 meter work, or would this be too granular since the other input rasters aren't at this resolution?

    Thanks for your help!

  • swolnyswolny Member, NatCap Staff
    Hi Pete -

    Wow, going from 3.3km to 1m, that's quite a change! There are a few things to consider about using a 1m resolution DEM:

    - Depending on the size of your area of interest, that might make a huge DEM file that will be computationally difficult, if not impossible, to work with. So clip it to your AOI and see how big the resulting raster is.

    - While it is fine for your different raster inputs to have different resolutions, the model will resample all of your other raster inputs to be the same resolution as your DEM. It's likely that this wouldn't negatively impact those layers (assuming they're all of a larger cell size than 1m to begin with), but it will compound the possible computational challenge.

    ~ Stacie
  • Hi Stacie,

    Thanks for the quick response!

    I'm still looking for a DEM around 30 meters, but yes, going from 3.3km to 1 meter seems like a bit of a change! I'll be careful about file size and hope the computational issues aren't too much to overcome. I'll be in touch with further questions and comments as I get everything organized. Thank you!

    -Pete
Sign In or Register to comment.