Coastal Vulnerability Model (v3.7): invalid geometries and projections

I’m running the new version of the Coastal Vulnerability model and getting an error:
WindowsError: exception: access violation reading 0x00000000

InVEST-Coastal-Vulnerability-log-2019-05-13–12_48_46.txt (3.5 KB)

Hi Monica, thanks for testing the new model! Would you mind sending me your data so that I can reproduce this error? davefisher@stanford.edu

Thanks!

Hi Dave, Here are the inputs I’ve been using. If the google drive thing doesn’t work, here’s the link: https://drive.google.com/file/d/1s5WYQL3qtDCq_9CMX854Zp0G7E9xGHiA/view?usp=sharing
CoastalVulnerability_Inputs_VicData_v37.zip

Thanks for sharing your data. The issue here is with the WaveWatchIII dataset. It looks like you chose to project the global dataset to match your AOI’s projection. That’s totally sensible, but since the original data includes points all over the globe, not all of the lon/lat coordinates transformed to the local projection you’re working with. Instead the transformation left some point features with no geometry, or maybe something undefined. The model crashed when trying to index those points.

Solutions:
Either use the WaveWatchIII.shp that is included with the InVEST sample data, which is unprojected (the model will handle the projecting appropriately). Or, select a subset of the points near your AOI and project only those. I tried both options with your data.

Thanks for getting back to me so quickly! That’s really interesting. I’ll switch to using the unprotected WaveWatchIII dataset.

I tried running the model using the unprojected WaveWatchIII dataset that came with the InVEST download and got the error: " ‘NoneType’ object has no attribute ‘IsEmpty’." All of the other data inputs are the same as the ones used previously.

InVEST-Coastal-Vulnerability-log-2019-05-24–10_00_48.txt (4.5 KB)

That’s an interesting one. It looks like the model completed some of its operations. What do you see in the intermediate folder? In one of the subfolders there should be a geopackage with the shore points. Do they look as you expect?

Hi Dave,

The shore points don’t show up, though the main.tmp_clipped_landmass does show up and looks normal. When trying to Zoom to Layer for the shore points, the view zooms way out and the land mass becomes a tiny speck. No shore points are visible at this zoom level either.

Okay, so the shore point creation depends on the AOI, the landmass vector, and the model resolution. I’m suspicious of the landmass vector you used (I’m looking at the parameter list at the top of your logfile). Though in that case I can’t explain why tmp_clipped_landmass looks normal.

Is there anything I can check with the landmass shapefile to make it work better? I tried reprojecting everything into WGS 1984 except for the wavewatchIII points and the AOI polygon (it made me keep it in meters), and I still got the same error.

Hi Monica, sorry to be obtuse. I was trying to walk us through a typical process of troubleshooting this stuff. From the logfile you uploaded, it looks like you mistakenly used the WWIII dataset as the landmass vector:
landmass_vector_path E:/TrainingMaterial/CoastalVulnerability_Inputs_VicData/WaveWatchIII.shp

If that is in fact the correct landmass layer, then I’m stumped! And you may send me your data to look at.

Hi Dave,

Thanks for catching that. I tried it again with the landmass layer in the correct field, but I still got the same error. I’ve attached the log file. The landmass file is large so I’m sending it via email. This was run on my Windows 7 machine.
InVEST-Coastal-Vulnerability-log-2019-05-30–09_10_21.txt (33.0 KB)

I’ve also been trying to get this to work on a remote access virtual PC setup so that people in our lab with Macs can get around some of the Mac issues. Using all the same inputs in the virtual setup, the sea level rise field name is stuck saying “UNKNOWN” instead of “Trend” and I am unable to click “Run”. I’ve attached a screenshot of this.

Hi Dave,

I think the attachment was too big to be received over email so here’s a link to google drive instead: https://drive.google.com/file/d/1Td7bfYO7PjVmqpA-eE6HpGjKnRoQiHn_/view?usp=sharing

Hi Monica, I tested your landmass dataset. The shore points look just fine, so I’m assuming the earlier issue about strange shore points was due to the incorrect landmass vector being used.

I was able to reproduce the error during the seagrass habitat processing. That stems from invalid geometries in the seagrass layer (note the TopologyException message in your log). I used a QGIS ‘fix geometry’ tool to clean up that layer, and the model ran successfully. As an optional step, I also completely dissolved the seagrass layer because it looked to contain many redundant vertices. The dissolved file is about 30% smaller in size. These are very common issues for vector datasets that have been created by some kind of raster-to-polygon operation. So some subsequent cleanup is usually a good idea.

Here’s a link to the cleaned up seagrass:
https://drive.google.com/open?id=1nKbGL9KxV3Oo3XbwURBG-hL0Bpnz1Yyg

Concerning your other issue of the ‘virtual setup’, could I convince you to open a new thread with that question, and also describe some details about the setup like which remote access software is being used and what happens when you try to change the dropdown menu? Limiting a thread to a single issue helps keep us organized here, and helps people find existing solutions. Thank you!

Hi Dave, Thanks for the tip on the seagrass and the raster-to-polygon issue. I will definitely remember that one. I’ll switch the other issue to a new thread.

Regarding the sea level rise field name, I made a copy of the Trend field and named it UNKNOWN. The red X disappeared and I was able to click run, so it looks like that issue is resolved too.

I’m trying out CV 3.7, and wanted to note that I also got geometry errors for several of my habitat shapefiles. They look like this in the log file:

2019-06-05 15:10:13,710 coastal_vulnerability.search_for_habitat(1306) INFO Searching for seagrass in proximity to shore points
2019-06-05 15:11:20,038 geos.callback(209) ERROR TopologyException: Input geom 0 is invalid: Self-intersection at or near point 390641.52591452003 1818593.9686564116 at 390641.52591452003 1818593.9686564116
2019-06-05 15:11:20,038 Task.add_task(636) ERROR Something went wrong when adding task searching for seagrass (10), terminating taskgraph.
Traceback (most recent call last):
File “Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\taskgraph\Task.py”, line 602, in add_task
File “Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\taskgraph\Task.py”, line 1068, in _call
File “Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\natcap\invest\coastal_vulnerability.py”, line 1356, in search_for_habitat
File “C:\Python27\lib\site-packages\shapely\ops.py”, line 131, in cascaded_union
File “C:\Python27\lib\site-packages\shapely\geometry\base.py”, line 76, in geom_factory
ValueError: No Shapely geometry can be created from null value

I tried using Repair Geometry in ArcGIS, didn’t help. Tried Fix Geometries in QGIS, didn’t help. Tried Fix Geometries in QGIS + Dissolve in QGIS and QGIS produced a broken result. Finally tried Fix Geometries in QGIS + Dissolve in ArcGIS and the model ran successfully.

So if anyone else comes across this error, I’d recommend doing both Fix/Repair + Dissolve, as Dave noted above.

~ Stacie

Thanks Stacie, what a pain!

I’m going to rename this thread since it’s transformed into mostly a discussion of geometries and projection issues.