Hi
I was working with the InVEST 3.5 Coastal Vulnerability with good results, however, I realised from the intermediate folder that the surge potential results weren’t correct, as for same distances I had different rank scores. InVEST-Coastal-Vulnerability-Assessment-Tool-log-2019-04-11–15_47_05.txt (22.2 KB)
One of the ideas I have for why this error may occur is because I input 2 data for the same aspect: bathymetry (raster) and the continental shelf vector (Polygon-InVest data).
I tried to run again the model using the new InVEST 3.7 CV. with the same data (no bathymetry this time) and using the new continental shelf polyline (InVEST provided) and I have errors.
I had seen from the new improvements in CV 3.7 is that the shoreline points are plotted directly on the coastline - no more “snapping” necessary. In case it was something to do with the landmass data, I’ve tried to fix and dissolve the geometry, but I still have errors.
Hi @Cari, thanks for the feedback. Would you be willing to share your input data (landmass polygon and AOI) so I can reproduce this error? It looks like some unexpected geometries are being formed when the model intersects these two layers.
We did do a lot of updates between versions 3.6 & 3.7. And we have some yet unreleased updates that you can get by installing the latest development version linked below. Specifically, we will again require a bathymetry raster input, for use in the wave exposure calculation. The surge calculation will still only depend on the shelf contour polyline.
Thank you very much for your help Dave. I’ve been trying to edit the landmass and I was able to run the model (v.3.7) successfully (although much more time of computation this time, with more than 7 hours). I have also realised some changes in the output files, with the v.3.7 compare to v.3.5. such as in the coastal_exposure.csv there is not coordinate as it was before but really useful to find an intermediate_exposure.gpkg file with the original data from each variable!
I’m going to install the new version you attached and try to run the model again. However, I don’t really understand why bathymetry was not required in the v.3.7 for wave exposure calculation and in the latest development version, it is required. I will test how this will impact on the final results.
You should find much improved runtimes with that new development build. Thanks for trying it out.
We really should have been requiring bathymetry all along, as water depth is an important input to equation 10 in the User Guide.
The 3.7 release uses H and T values for equation 8 that represent open ocean wave heights and periods. That’s fine for the P in eq. 6, but for the P in eq. 9 we should use local wind-driven wave heights and periods. So those H and T should be estimated with eq. 10. And we have corrected that in the development build.
Interesting to see how that impacts your results, it may be subtle by the time things are binned to the ranked R_wave and then the final exposure index.
Thanks, Dave for clarifying this. I’ve installed v 3.7 developer version and I input the bathymetry, I’ve run the model twice
Once using the GEBCO 2014 Bathymetry (1km approx, resolution) and another time using GEBCO 2019 Bathymetry (500m resolution) (Esri ASCII raster format) with depth in negative values. I’ve extracted by mask both with the AOI.
In both cases, I had an error. Do you think this is something related to the data input?
Thanks for testing this version for us! I don’t think this error related to the input, rather I think it amounts to a syntax error in some debug statements of the code. So sorry for that! I should have another build ready very soon with some other minor changes we want in the next release. I’ll post back here.
Unrelated to this error, I think it’s best to not mask out the bathymetry using the AOI. The model extracts bathymetry data using the fetch rays, and those can extend beyond the AOI boundary, depending on the max_fetch_distance parameter. So I’d suggest being generous with the bathymetry coverage (same goes for other inputs) and let the model clip it down as needed. See intermediate/wind_wave/fetch_rays.gpkg for the coverage of the rays.
For what it’s worth, I’m using GEBCO 2014 bathymetry for a CV project and haven’t had any related errors. I don’t clip it or process it at all, for the reasons that Dave gave, but it is in TIFF format, so could it be worth converting to (or leaving it as) TIFF and see if makes a difference?
Thank you very much for your help Dave and the model improvements. I have ran the model again today twice, successfully, however when I try to open the .gpkg files (coastal_exposure and/or intermediate) in QGIS I can not, it says invalid format. What do you suggest could be wrong this time?
Thank you very much for your help.InVEST-Coastal-Vulnerability-log-2019-11-18–14_47_56.txt (677.0 KB)
I am using QGIS 2.8.3. The InVEST sample files load without any problems. I have tried to load all the gpkg files obtained after the last run and none load. I have noticed that the metadata on the files just says error.
Yes, I expect updating QGIS will help, please let us know! It’s probable that the new invest outputs were created with a GDAL version that is not supported by the older QGIS. We build invest against GDAL 2.4 at the moment.
Thanks so much for all your help!