The model no longer continues to run while Casting rays and extracting bathymetry values. It was stuck from 2pm to 5pm and would not continue to run.
InVEST-Coastal-Vulnerability-log-2024-07-01–12_40_07.txt (74.1 KB)
Hi @tzlhhu0116 , thank you for posting your logfile here.
I see two issues:
- You are running invest version 3.12.1. The latest version is 3.14.2. There have been multiple bugfixes since 3.12.1 that relate to the fetch rays and bathymetry processing.
- This message in the logfile is concerning:
2024-07-01 14:18:30,961 (natcap.invest.coastal_vulnerability) coastal_vulnerability.prepare_landmass_line_index_and_interpolate_shore_points(837) INFO Finished creating 2 shore points in AOI
It indicates that only 2 points were created along the coastline in your AOI. I encourage you to look at some of the intermediate files in the output workspace to understand this better:
intermediate/shore_points/shore_points.gpkg
intermediate/shore_points/clipped_projected_landmass.gpkg
My best guess is perhaps your AOI input or your landmass input has an incorrectly defined projection. I would examine all of your input data in GIS to determine this.
Casting rays and extracting bathymetry values ，Running for more than 12 hours without further calculations.
InVEST-natcap.invest.coastal_vulnerability-log-2024-07-08–15_28_18.txt (48.3 KB)
Hi @tzlhhu0116 , I moved your post to this existing topic because it seems like a continuation of the same problem.
Thank you for updating to the latest version of invest. I see from the log that the model is now creating 85 shore points instead of only 2. Is that what you would expect for your Area of Interest?
If you would like, you may share your input data with me and I can try to reproduce this issue. You may send me a direct message if you prefer not to share your data publicly.
Thank you for your reply, this run was a different attempt in a different area than the last. I will attach my input data and hopefully you can help me with the problem I am having, thanks again for your help!
to dave.zip (1.7 MB)
Thank you @tzlhhu0116 . There are some files missing from the zip folder. Shapefiles are actually composed of several files with different extensions, not just the .shp files. For convenience, you could use the InVEST Workbench to package your data (An easy way to share data using the InVEST Workbench)
Uploading: invest_coastal_vulnerability_datastack.zip…
I think this should be the package of files you need, since .tgz files can’t be uploaded to the dialog, I changed it to a .zip file, thanks for your patience!
Thanks again. I’m afraid the zip file did not finish uploading before you posted your message. I wish this site would prevent that from happening.
Another good option is to upload to a filesharing site (google drive, dropbox, etc) and then share a link to that.
invest_coastal_vulnerability_datastack.zip (1.8 MB)
Would you please try again?
Got it, thank you! There are a few issues to deal with.
First, the input data seem to have an incorrectly defined coordinate system. The system is defined as,
Name: EPSG:32619 - WGS 84 / UTM zone 19N
Units: meters
But the coordinates, such as the extent of the AOI, are,
109.6206202631684050,18.3593145628195771 : 111.6610080756678940,20.2212427998816224
With units of meters, this makes the AOI only about 2 meters x 2 meters wide. Instead, these coordinates appear to be decimal degrees (longitude, latitude). So, if I redefine (not reproject) the coordinate system to a geographic system, such as EPSG 4326, WGS84, then the data appears to make sense.
You can verify these things by looking at your data in GIS and adding a reference map, such as data from Natural Earth » 1:10m Cultural Vectors - Free vector and raster map data at 1:10m, 1:50m, and 1:110m scales
Second, for this model, it is not a good idea to clip your input data to the boundary of the AOI. Please see the Area of Interest section of the User’s Guide for more details: Coastal Vulnerability Model — InVEST® documentation
In particular, it is almost always best to use this model’s sample data with global coverage for the WW3 layer and the continental shelf layer. The landmass and bathymetry layers also must extend well beyond the AOI in order to have accurate wind & wave results, based on the ray-casting function.
When I switched to the projected coordinate system of WGS_1984_UTM_Zone_19N, his coordinates changed directly to what you see here. However, in my previous attempts at a trial run without the presence of habitats, it was able to run successfully. What projection coordinate system would you suggest I change to that would be better?
I am suggesting that despite the fact that the coordinate system is currently listed as,
Name: EPSG:32619 - WGS 84 / UTM zone 19N
Units: meters
In actual fact the coordinates of these layers are decimal degrees, not meters:
109.6206202631684050,18.3593145628195771 : 111.6610080756678940,20.2212427998816224
Aren’t these values the longitude and latitude of Hainan, China? But the assigned coordinate system is forcing all GIS software, including InVEST, to interpret these numbers as meters and placing your data in the wrong location on Earth.
Dave, after your last pointer answer, I appear to have successfully solved the coordinate system problem, and the coordinates have now changed to the linear form below (37367552.538791 m 284741.281614 m). However, I have encountered a new error, could you please help me to see which part of the problem is occurring?
@tzlhhu0116 I’m glad you solved the coordinate system problem. Did you intend to upload a new logfile with the new error?
I’m sorry that I sent it to you before the upload was finished yesterday. Could you please help me check the problem? Thank you very much！
InVEST-natcap.invest.coastal_vulnerability-log-2024-07-15–16_01_22.txt (4.9 KB)
Hi @tzlhhu0116 , this error sounds similar to the first one discussed over here: Coastal Vulnerability Model (v3.7): invalid geometries and projections - #4 by dave
And I see you also are not using the WaveWatch3 dataset that comes with the model’s sample data. So the first thing I would try is to use the layer from the sample data directly unless you have a clear reason for using your own.
I just projected the WWIII file in the sample data and made a new attempt after extracting some data points according to the topic you posted, and it seems that I still encountered the same problem as before, but the shore points are normal!
InVEST-natcap.invest.coastal_vulnerability-log-2024-07-17–08_54_26.txt (4.6 KB)
Based on the other thread I linked, I think this is the problem. Projecting data from all over the globe into a local coordinate system can result in some strange or unexpected results.
Please try using the WWIII shapefile from the sample data without altering it.
Something went wrong when adding task calculate surge exposure (6), terminating taskgraph.Traceback (most recent call last):
File “taskgraph\Task.py”, line 674, in add_task
File “taskgraph\Task.py”, line 1093, in _call
File “natcap\invest\coastal_vulnerability.py”, line 2045, in calculate_surge_exposure
AttributeError: ‘NoneType’ object has no attribute ‘Intersection’
07/18/2024 09:12:32 natcap.invest.utils ERROR Exception while executing natcap.invest.coastal_vulnerability
Traceback (most recent call last):
File “natcap\invest\utils.py”, line 165, in prepare_workspace
File “invest\cli.py”, line 470, in main
File “natcap\invest\coastal_vulnerability.py”, line 938, in execute
File “taskgraph\Task.py”, line 674, in add_task
File “taskgraph\Task.py”, line 1093, in _call
File “natcap\invest\coastal_vulnerability.py”, line 2045, in calculate_surge_exposure
AttributeError: ‘NoneType’ object has no attribute ‘Intersection’
I switched to using the WW III wind and wave data points from the original sample data and still have this problem.
Great, this is a new error and not related to the WW3 data. This error is related to the surge calculation, which uses the continental shelf contour layer. I would examine that layer for the same sort of issues related to coordinate systems that we have already discussed.