Surface volume tool results in NaN values

[DevonMoore]

I am attempting to calculate the volume of basin raster files with depth-related z values using the surface volume tool. This process has mostly been successful, however in some cases I receive the following error code under the volume field in the output table: 1.#QNAN. It should be noted that I am only receiving this error with specific data sources.

A bit of background on my intent:

All of my raster inputs originate from two types of georeferenced point datasets corresponding with depth and aquatic vegetation %biovolume values obtained from SONAR mapping of lakes*. To create the raster files, I interpolate the point data using the spline tool and clip to the appropriate spatial extent polygons. I then use raster calculator with the depth and %biovolume rasters as inputs to define a new 'depth to vegetation' (DtV) raster. The depth and DtV rasters then become the inputs in the surface volume tool. I subtract the DtV volume from the Depth volume to obtain a total vegetation volume for a given area.

*I perform the mapping myself and upload the SONAR files to an online service that QCs the data and produces a summary report. I can then export this processed data in the form of an XY table.

My understanding of the issue:

So far I haven't determined an underlying cause for the QNAN error, just that it occurs only in the Volume field of the output table and only with the DtV raster files (raster calculator output) of some of the older datasets. In my attempt to troubleshoot, I noticed that the depth and %biovolume points typically line up perfectly when imported into ArcMap as point shapefiles. However, in the older datasets, these points are not aligned--which is the only noticeable difference. I have attempted to remedy this potential issue by aligning the depth and %biovolume cells before performing the raster calculation, but this has not worked. 

I've tried looking into the root cause of the 1.#QNAN error, but haven't found anything conclusively tied to the surface volume tool. If anyone has any experience with this issue, please assist.

Thank you!

[DanPatterson_Retired]

If you are using geographic coordinates for X, Y and planar units for Z, or an invalid extent then it might popup this error.

Here is a blog post that describes determining appropriate z-factors and extents

Determining a Z-factor for scaling linear elevation units to match geographic coordinate values 

Then there is BUG-000100049: The Output Extent environment setting is not honored.. 

Which says ... in production plan but the post was from 2017 (???)

[DevonMoore]

Dan,

Thanks for your quick reply. I am cognizant of the need to coordinate XY and Z units. Since my XY data is imported in WGS 1984 and the Z units for depth are in feet, I reproject the point shapefiles to an appropriate coordinate system using feet as linear units before performing any geoprocessing. I've also looked into the bug report you've linked, but I believe I have circumvented this issue by preemptively clipping my raster files to the appropriate extent prior to running the surface volume tool.

As mentioned, I've been using the surface volume tool without issue on both the Depth and calculated Depth-to-Vegetation (DtV) rasters. I'm only receiving the 1.#QNAN result with the calculated DtV raster files on a few of my "older" datasets. The input Depth and %Biovolume rasters which I use to derive the DtV raster are using the same cell resolution and I've made sure the cells are aligned properly before performing the raster calculation. There is no difference in the layer properties between the Depth and DtV raster files I'm using. I've also looked into the parent XY tables (CSV format) and the data type/formatting from the old and newer files are identical. The DtV rasters have cell values as evidenced by the presence of statistics and the ability to generate a histogram of these values. I simply don't know what potential causes there are for a QNAN error using the Surface Volume tool, therefore I am unable to pinpoint an area to focus on. 

Would my version of ArcMap be an issue? My organization is still running version 10.1. 

[DanPatterson_Retired]

Devon, A lot has happened since 10.1 but I am not sure where you would find out since it isnt supported anymore

Esri Support ArcMap 10.7 (10.7.1) 

The only thing I could suggest now is find someone with a newer version and get them to test a 'no-good' and 'good' file to see if it is version related.

Also, ArcGIS Pro might be an option.  

In any event, I would get them converted to locally stored featureclasses in a file geodatabase.