I’d appreciate any thoughts on an issue I’m running into (datastack here):
What is the issue or question you have?
Receiving lots of warnings to the effect of “found fetch ray at shore_id # with no bathymetry data, assuming depth of -1 for wave height & period calculations.” The model completes eventually however.
What do you expect to happen?
Expect to have complete bathymetry data for rays
What have you tried so far?
It’s hard to diagnose this through the intermediate files. It looks like there are some missing depths in the fetch_points.gpkg file, though they do not seem to be equal to the number of times the warning is printed after looking at a small sample of points. The negative_bathymetry.tif is completely nan, which seems like a problem, but then I’d expect there to be no bathymetries present in fetch_points.gpkg unless it grabs those from the input raster vs negative_bathymetry.tif. Also, not sure why it would be nan, as it is a seamless topobathy that follows the similar negative/positive values format of the global dem in the base data, and “positive_dem.tif” does not have any apparent issues.
I’ve run the model using the global dem base data tif and not run into these errors and it completed.
There are some overland points I don’t need that are an artifact of my shoreline boundary being a national polygon layer, but the problem does not seem to be arising from that, as the warnings flag nearly all shore_ids.
The negative_bathymetry.tif is completely nan, which seems like a problem,
I agree. In all likelihood this a bug in handling of nodata from the input bathymetry, which I noticed did not have a defined nodata value. According to our changelog, we should already be handling that case, but something seems to be amiss. I’ll dig in a bit more this afternoon.
Hey @rmgriffin , I confirmed that your bathymetry raster works well once it has nodata value defined. So that’s a bug on our end, but for now you should be able to use this raster, which has a nodata value of 99999.9.
I ran this through InVEST 3.13.0 which actually behaved a bit differently than 3.11.0. I encountered an error with the original dataset as opposed to all the warnings you saw. I would guess this new dataset will work in either version, but I only tested it in 3.13.0.
This is still puzzling if it’s true. The bathymetry data gets stored in columns named fdepth_<direction> in fetch_points.gpkg. Those values should represent the average of the bathymetry values found from negative_bathymetry.tif, along each fetch ray. Many will be NULL for the fetch rays that point towards land.