How does z_factor affect Surface Volume (3D) units?

[AustinMilt]

What are the units of volume output by Surface Volume (3D) when a non-default (=1.0) z_factor has been specified?

I am working with a DEM which has lateral (xy) units of meters and vertical (z) units of centimeters. I need to calculate the volume below a height (measured in centimeters). I have used the following syntax to do this:

arcpy.SurfaceVolume_3d(r'C:\mydem.tif', r'C:\mycsv.csv', 'Below', height, z_factor=0.01)

Assuming this is the correct specification, will the output units of volume be cubic-meters, or cubic-centimeters? The values I am getting lead me to believe the units are cubic-centimeters.

Note some related topics/questions:

Correct base_z (height) for Surface Volume (3D) with z_factor != 1?‌

https://community.esri.com/thread/181692-correct-units-for-zfactor-in-surface-volume-3d‌

Units for Surface Volume tool‌

[DanPatterson_Retired]

using the logic of 0.34ish feet/meter when x,y is meters and z in feet, I would say 100 cm/meter is your conversion, giving the suggested difference factor of 10^6 as suggested in the last link.  If in doubt, do a sample, your answer will seem either wildly off or slightly less confusing... I would go with the later

[AustinMilt]

Thanks for your reply Dan. That suggestion in the last link was my own, and unfortunately it's just a guess. My hope in creating a separate topic was to put this thing to rest with a definitive answer from someone with extensive experience with the tool or direct knowledge of the programming. Perhaps, as you suggest, I should just go create a toy raster with known units and experiment, though it would be much more satisfying to get it directly from the horse's mouth (as they say).

[DanPatterson_Retired]

As in the height link... of which there are now many... you need to do the calculation yourself, your error will be a factor of 10^4 which for a calculation in a small area, only one is going to seem correct and the other is going to be wildly off... I haven't even done the math, nor do I purport my answer to be correct, but that is how I address binary answers.... one is going to be right and one is going to be really wrong, ergo my feet/meter example, 0.34ish is a long way from 0.01ish and why people are less comfortable with the feet to meters thing than they should be with the centimeters to meters thing.   By extension, what would you do if the elevations were recorded in millimeters? now your margin is 10^6

As a tip, the feet to meters conversion the 0.34ish is what you multiply your feet values to get an approximation to feet, so if you have a height of 3ish feet, it is 1ish meters

[AustinMilt]

I created a toy raster with the following values:

30 30 30 30

30  0   0  30

30  0   0  30

30 30 30 30

and a projection of NAD_1983_Albers, with 30x30 m cells (to match my DEM motivating the issue). I then ran Surface Volume (3D) with the following settings:

Reference Plane: BELOW

Plane Height: 30

Z Factor: 0.01 **Note I was not allowed to change this value in ArcMap; it was interpreted by default from the projection.

Based on my multiple open topics, here are results I could expect given those inputs:

• plane height is in meters, z factor is m/cm: volume = (30 m)*(30 m)*(30 m)*(4 cells) + (30 m)*(30 m)*(29.7 m)*(12 cells) = 428,760 m^3
• plane height is in centimeters, z factor is m/cm: volume = (30 m)*(30 m)*(0.3 m)*(4 cells) = 1,080 m^3
• plane height is in meters, z factor is in cm/m: volume = (30 m)*(30 m)*(30 m)*(4 cells) = 108,000 m^3
• plane height is in centimeters, z factor is in cm/m: volume = (30 m)*(30 m)*(0.3 m)*(4 cells) = 1,080 m^3

The actual results are... 241,650 somethings^3. 

My conclusion: either I dont understand what this tool is doing (and my topics asking for more explanation are well-founded), my experiment was flawed, or there's something very wrong with the tool.

If anyone can shed some light on the topic, I would be really appreciative.

[DanPatterson_Retired]

Well this comment would tend to throw any attempt at manual calculations off since cell extent is not how it is done (from the link at the start of your post).

A raster surface is evaluated using the extent of the center point of each cell, as opposed to the extent of the entire cell area. The resulting analysis will decrease the data area of the raster by half a cell relative to the data area displayed for the raster.

[AustinMilt]

Thanks for your reply. Can you explain what the statement means? Does it mean that the result is half as big as expected, or that the volumes for all pixels along one side are half as big, or that volumes for all pixels along the border are half as big, or that the result will be off for one pixel? The statement in the documentation, while pointing to one reason why I might have different results, still obscures how one would go about calculating surface volume using their technique, and thus from understanding how I should specify inputs to the tool.

[DanPatterson_Retired]

I will have to run an example myself to check the math... currently on iThingy, so no Arc* access