Dear users and developers,
I have ran the InVEST 3.8 and InVEST 3.8.2. It shows error:’'Dataset must be projected in liner units",but the same data can be run in InVEST3.7. The dataset I used in the projected coordinate system: TWD 1997 TM Taiwan.
I managed to run InVEST3.7 successfully, but the deg_sum map was 0 ~ -2821.66.
I tried several times and still got the negative value. Anyone can help me to solve the problem?
Hi @fwy1002,
Thanks for posting. That does seem odd about the landcover raster. Do you think you could attach the raster here? Or if it’s too large, share it via a file share like Google Drive, or another service?
Thanks,
Doug
Hi @fwy1002,
I can’t seem to reproduce your issue with InVEST 3.8.0 or 3.8.2. The LULC_c
raster loads without issue in the user interface. In the user interface, could you go go Edit
- > Clear Inputs
and try to enter the raster again?
Doug
As for the bad results your seeing, it looks like something is failing during the decay of the threats. There’s a known bug that we’ve recently patched that is not released yet with doing this decay and convolution. A workaround might be altering the MAX_DIST
in the threat table. Since your LULC is about 1200 x 1200 meters, do you think you could scale back your MAX_DIST
which is in km
in the threat table? The exponential
decay for threat road
especially. I might try 1,1,1 down the board. That would basically decay across the entire LULC have still, but may provide stability to the bugged algorithm.
You can look at intermediate/filtered_road_c.tif
to see the bad output currently and after you re-run to see if it looks more appropriate.
Doug
Thank you for your advice. I go “Clear Inputs ”and try to enter the raster again ,but still can’t run the InVEST3.8 and InVEST3.8.2 successfully. I will try to modify the threat table,Thanks again.
Just to chime in here, we made a few changes to how validation works in the user interface between InVEST version 3.7 and 3.8, and one of these changes was to require projected datasets (in linear units such as meters) for the model inputs that needed them. So that’s why you’re seeing the error in 3.8 and not in 3.7, but it doesn’t explain why @dcdenu4 isn’t able to reproduce the issue with your inputs … that part is strange.