Coastal vulnerability ValueError cannot convert float NaN to integer

I’m having trouble running the coastal vulnerability model for the state of Maryland. I’ve previously run the model successfully for the state of North Carolina and have compared the input datasets for each, but keep getting errors when running for MD. As I’ve made tweaks to the input datasets for MD, the error codes I get differ; the latest one is a ValueError: cannot convert float NaN to integer, which looks like it might be related to the relief raster? My log file is attached; I can put the input datasets on the cloud if that would be helpful. Thank youInVEST-Coastal-Vulnerability-log-2020-04-16--09_05_55.txt|attachment (10.3 KB)

Hi @kwarnell,

It looks like the log didn’t attach correctly. Could you try attaching it again?



Hi Doug,

Absolutely; here it is again. Thanks for looking into this!


InVEST-Coastal-Vulnerability-log-2020-04-16–09_05_55.txt (10.3 KB)

@kwarnell, the log here is pretty strange. First, I’m not sure what to make of all those DLL errors from gdal. That may or may not be related. Second, it’s strange that the log doesn’t mention creating the shore points. That is a pre-requisite of some of the steps that are logged, like calculating wind exposure.

Do you have any intermediate data in the workspace to explore? Specifically intermediate/shore_points/shore_points.gpkg and clipped_projected_landmass.gpkg? If those look strange, it could mean an incorrectly defined coordinate system on the AOI or landmass inputs.

@dave, I think the gdal errors are related to my recent installation of another program that required some gdal plugins; I’ve moved all of the plugins mentioned in those errors to the optional-plugins folder and they didn’t come up when I just reran the model (I’m also not sure whether they were related since the NC model ran fine yesterday even though it gave those errors at the beginning). I reran a few minutes ago in a new workspace to get a clean version to share and got a different ValueError (log attached).

It doesn’t look like it created any shore points (the two intermediate files you mentioned exist but are empty); I have viewed the AOI and landmass inputs in GIS and they display as expected and have the same coordinate system, so I don’t think that’s the problem, but I can share those with you if that’s helpful.

InVEST-Coastal-Vulnerability-log-2020-04-16–13_51_06.txt (17.1 KB)

Okay, thanks. This log is more informative. Since there are no shore points created, something about the landmass and/or AOI is problematic. Normally I would double-check the coordinate system - which you’ve already done. Is your landmass layer a polyline by chance? The model is expecting a polygon.

If you would like to share your AOI and landmass layers I will take a closer look!

It turns out the landmass layer I was using was a polyline - I was aware that might be an issue and had created a polygon version, but didn’t update it during the last model run. I just tried with the polygon landmass and am still getting an error. The log file from the latest run, and the AOI and landmass files are attached.

InVEST-Coastal-Vulnerability-log-2020-04-16–15_27_03.txt (6.1 KB) (112.4 KB) (2.7 MB)

@kwarnell, thanks for sharing your data. This revealed a small bug in the model, which we’ll fix. Thanks for helping us debug that!

In the meantime, a workaround is to slightly modify the AOI. The problem seems to be that the AOI and landmass have some nearly identical edges in some places, so when the landmass is clipped by the AOI polygon, it results in some unexpected geometries. The AOI is meant to delineate which parts of the landmass to include/exclude, so it’s not really helpful if they have exactly the same edge anyway.

I buffered your AOI by 10 meters and then successfully ran the model. Presumeably you could do a negative buffer if you wanted to exclude those parts of coastline instead. (157.0 KB)

@dave, thanks for the update! I tried a negative buffer as you suggested and successfully ran the model. I appreciate all of your help with this!

You can avoid this with a mask method. Note first that in python NaN is defined as the number which is not equal to itself:

>float('nan') == float('nan')      

It might be worth avoiding use of np.NaN altogether. NaN literally means “not a number”, and it cannot be converted to an integer. In general, Python prefers raising an exception to returning NaN, so things like sqrt(-1) and log(0.0) will generally raise instead of returning NaN. However, you may get this value back from some other library. From v0.24, you actually can. Pandas introduces Nullable Integer Data Types which allows integers to coexist with NaNs. Also, even at the lastest versions of pandas if the column is object type you would have to convert into float first, something like:


NB: You have to go through numpy float first and then to nullable Int32, for some reason.