Running Seasonal Water Yield Value Error

Hello! First of all I am impressed by this wonderful INVEST software! I am working with the city of Cordoba AR, I have already run all the models with success but I have a problem that I have not been able to solve with other queries from the community. With Seasonal Yield Water I get an error with the precipitation directory files: when I export the raster from arcmap it generates besides the .tif a .tfw and .xml file. If I leave them in the folder an error occurs, and if I delete them from the directory the geospatial reference is lost and the limits of each file do not match. What can I do? THANK YOU



InVEST-Seasonal-Water-Yield-log-2021-10-18–02_19_37.txt (3.2 KB)
InVEST-Seasonal-Water-Yield-log-2021-10-18–02_22_25.txt (8.4 KB)
InVEST-Seasonal-Water-Yield-log-2021-10-18–02_23_36.txt (3.2 KB)
InVEST-Seasonal-Water-Yield-log-2021-10-18–02_39_57.txt (8.4 KB)

If you are posting about a specific InVEST error, please do the following,

  1. “Search” on this forum with keywords from the error - the answer may already be here!
  2. Use the “Upload” button to attach the logfile (.txt) from your invest model’s output workspace.

Hi @nestorjerizzi -

It’s great to hear that the models have mostly been working for you. It is true that we must only have the .tif files in the precipitation and ET0 directories, and not any of the other [raster].* files. But the .tif should still contain the raster’s coordinate system.

Thanks for posting your log files. I see a couple of different types of errors occurring:

1/ ValueError: Ambiguous set of files found for month 1: [‘D:/ARQUITECTURA VI/elaboracion tesis/2a PARTE/34-18SEP21/10-seasonal water yield/INPUTS/PRECIPITAC/precip-aoi-soloTIF/corr-preci2\p1_1.geo’, ‘D:/ARQUITECTURA VI/elaboracion tesis/2a PARTE/34-18SEP21/10-seasonal water yield/INPUTS/PRECIPITAC/precip-aoi-soloTIF/corr-preci2\p_1.tif’]

This one is caused by having two files in the precip directory whose file name ends in “_1” (p1_1.geo and p_1.tif). There can only be one file for each month, ending in that month’s number (_1, _2 … _12).

2/ ValueError: Bounding boxes do not intersect

This error shows that it is finding the coordinate systems, but some the layers appear not to overlap the other layers. Usually this means that all of your spatial inputs do not have exactly the same coordinate system. Can you double-check that all of your spatial layers do have exactly the same projected coordinate system?

~ Stacie

Hi Stacie, thank you very much for your time. I have looked at both errors closely and they arise for the same reason: when the .tif raster is generated other .tfw and .xml files are stored. If I keep them in the same directory, “Ambiguous set of files found for month 1…”. If I keep only .tif in the directory and delete the rest, “Bounding boxes do not intersect…”.
Yes they are all projected in the same coordinate system and with the same “Extent” values.
I am not getting a .tif file that keeps its spatial reference without the .tfw.

1 Like

That is curious @nestorjerizzi, I have used this model a lot and have never had a problem only storing the .tifs in there (although it does seem like a good RFE that the model be able to handle having those other files in the input folder…) Which GIS are you using to create these layers? If you have just the .tif in a directory and open that in the GIS, what does it say for coordinate system?

~ Stacie

1 Like

Evapotranspiration rasters are obtained from ESA-SENTINEL SNAP, then processed with ArcMap. Precipitation rasters are from worldclim.org. In both I have had to re-project to a single coordinate system (WGS_1984 UTM Zone 20S) that I have used in all other models. Then “Georeferencing” with control points, matching with the working area shape, and finally “Update georeferencing”.
I have separated two directory options: one that has all the file types that accompany the .tif, and one that only contains the .tif files. When I open the first option in Arcmap, the Extents of the raster match all the other files in the model and the coordinate system is WGS_1984 UTM Zone 20S. When I open the second option the coordinate system is the same, but the Extents are different. I am attaching a link to a folder that contains all the files to run SYW (includes the two directory options of Precip and Evapotransp). SYW Files - Google Drive

I have solved it. The thing is, if I use a .tif that was created with another coordinate system it depends on the .tfw file to locate itself in my own coordinate system. The problem is that INVEST SWY does not allow the .tfw file in the same directory as the .tif. What I did was to create a new raster for each month (precipitation and evapotranspiration) starting from my Coordinate System and my Extents. That raster created by me, even if I delete the .tfw, keeps the coordinates and extents data.
https://drive.google.com/drive/folders/1rZF6WBuEitqNTU59FtcaLyE98ycT2sbT?usp=sharing
https://drive.google.com/drive/folders/1KfkUzsptE-BlmaB7gg71UF3I_lue4n30?usp=sharing

1 Like

Thanks for the follow-up @nestorjerizzi, I’m glad you figured it out. And I’m trying to understand exactly what changed for it to work. When it didn’t work, am I correct in reading that you started out with whatever coordinate system the data originally came in, then processed it and reprojected it to your own coordinate system? Then when it did work, you first reprojected the source data to your coordinate system, then did whatever processing was needed?

While I have used WorldClim precipitation data many times, I’ve never georeferenced it, so perhaps it’s something in the georeferencing that affects the coordinate system definition?

Anyway, I hope the rest of the process goes smoothly for you.

~ Stacie

2 Likes

Stacie, thank you for replying and apologies for my English language, I really hope the messages have been understood. I have accompanied my messages with the corresponding files to serve as proof. When it did NOT work, I had used data that was in another coordinate system (eg. precipitation from worldclim.org in GCS_WGS_1984) and to match my own boundaries of the area of interest I had to reproject to my project coordinate system (WGS_1984_UTM_Zone_20S). That process makes the reprojected raster depend on a .tfw file for its geographic position, which is hosted in the same directory as the .tif.
When it DID work I used raster files I created myself that copy the data from the other downloaded ones, but this time they are created in my coordinate system. Although the .tfw file is also generated, by removing it from the directory (to work with the condition “Only .tif files should be in this folder (no .tfw, .xml, etc files).”) the raster does retain its geographical position.
I’ve been able to get it to work and I’m impressed with the results. I want to thank you for your dedication to your project and look forward to using INVEST to bring better data to the cities in my region. Best regards!

Thanks @nestorjerizzi for elaborating, it might help someone who runs into this same problem later. :slight_smile:

~ Stacie

1 Like

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