To calibrate InVEST 3.8.4 we selected sub watersheds with different land uses and topographies. The problem we faced is that the calibration coefficient does not work for the whole sub watersheds and calibration is very time consuming. On the other hand we get different answers by changing different coefficients and scenarios. My question is whether to consider and calibrate the whole of watershed with the final outlet? Is the resulting calibration coefficient correct for other sub watersheds? Or should different coefficients be obtained for each sub watershed? Is there a coefficient to adjust the sediment delivery of each LULC class(like sedret_eff).
On the other hand, in this version, the output of the shipfile is empty(#natcap-software-support ).
Hi @mostafa.keshtkar , I don’t have the experience to advise on your calibration questions, but I can help to determine why the output shapefile is empty if you like. Can you start by uploading your logfile from the output workspace? And it is also worth trying the latest version of invest
Thanks for sharing your logfile. The reason the output shapefile is empty is mentioned in messages like this from the log:
2021-01-29 19:31:57,902 geoprocessing.zonal_statistics(1169) ERROR aggregate vector J:/rosob_lorestan/run/kamandan_chamchit\watershed_results_sdr_RunVk_32_50_K0.8_ic4_SDR0.3.shp does not intersect with the raster (‘J:/rosob_lorestan/run/kamandan_chamchit\sed_deposition_RunVk_32_50_K0.8_ic4_SDR0.3.tif’, 1)
Can you confirm that the input watersheds vector overlaps with the input DEM & LULC rasters? If nothing looks strange, you may share your input data with me (with a google drive/dropbox link here or in a private message) and I can take a closer look.
If the output rasters look okay then I would guess the problem is with the input watersheds vector.
One thing about ArcGIS is that it will dynamically reproject spatial layers that are in different coordinate systems, so they look like they overlap, and so it can do computations on the layers. But SDR expects all layers to be in the same projected coordinate system, it does not reproject. Because of this, InVEST does check for for mis-matched coordinate systems, and gives an error in the user interface, so this may not be the problem. But, it’s worth verifying that your spatial inputs are all in exactly the same projected coordinate system.
Ah ha! Here’s the problem. The user-interface for SDR is allowing different coordinate systems for different layers (so long as they overlap if projected to common system), but then SDR does not do that reprojection when the model is executed. So, that’s a bug in the UI that we’ll fix.
Like Stacie says, putting all the inputs in exactly the same projected coordinate system should solve the problem (and is always a good idea).