Update how to determine depth dimension

[ssuttles-usgs]

Update needed because P_1 variable can and often does include pressure due to things other than sea water (e.g atmosheric pressure). Best practice would be to use the WATER_DEPTH and initial_instrument_height attributes to determine the depth dimension because it is expected that WATER_DEPTH attribute was determined relative to a water level datum (e.g. Mean Sea Level, Local Mean Sea Level, or ground water table).

[dnowacki-usgs]

Thanks for the PR, Steve. I agree with this:

Update needed because P_1 variable can and often does include pressure due to things other than sea water (e.g atmosheric pressure).

Agree, and note that the P_1 standard_name of sea_water_pressure does allow for air pressure variability. As an aside, we have been adding a 1 m pressure offset to Nortek instruments which cannot handle negative pressures in order to avoid problems from changes in atmospheric prior to/after a deployment when the reading would be close to zero and potentially negative without the offset. In this case, P_1 would really not reflect pressure due to sea water alone .

I don't think this part reflects the reality of most WATER_DEPTH attributes I have dealt with:

because it is expected that WATER_DEPTH attribute was determined relative to a water level datum

In my experience, WATER_DEPTH is often simply the depth of water at the site at the time of deployment. This can make a big difference in shallow/intertidal sites as you know. Often I see "WATER_DEPTH_source" or similar as "ships echosounder", which suggests a moment-in-time water depth and not one tied to any datum. Even though WATER_DEPTH in OFR 2007-1194 says it's the "Best version of water depth at site" this hasn't been my experience.

I agree that if P_1ac does NOT exist, we should use something WATER_DEPTH derived, but I wonder if that's the best route if P_1ac does exist.

Thoughts?

[dnowacki-usgs]

What if we use attrs based on the CF Conventions standard names to indicate which depth we are talking about, and then use those values if present to compute the depth variable? For example, we could specify one of the following

[ssuttles-usgs]

I agree in the past WATER_DEPTH was often taken as the nominal depth at the time of deployment, but we have since decided WATER_DEPTH should be ref to a datum, typically some estimation of local mean sea level (LMSL). In my work group, the workflow is if we have corrected pressure data we use it and initial_instrument_height to find local mean sea level from the data and use that for WATER_DEPTH attribute, in the same manner that create_z does. Alternatively, if have height_above_geopotential datum available use it in VDatum to estimate LMSL, which is used for WATER_DEPTH. It is unfortunate that the OFR is not more clear about WATER_DEPTH.

I like your idea about the CF standard name to know what WATER_DEPTH actually is. Flexibility is a plus. Just makes for a bit more coding, but I agree that is a good approach.

One more thing. We should also add D_3 to the 'if' tree for calculating depth from the data. The situation that prompted this PR was where there was P_1 and D_3 (Hobo water level data above sensor corrected for atmospheric in the Hobo software). It used P_1, which was absolute pressure and gave an erroneous value for depth. So solution, remove P_1 and add D_3 for cases when WATER_DEPTH is not ref to datum?

[dnowacki-usgs]

Then replace this line with if not depvar:

[ssuttles-usgs]

instead used --> if depvar is None:

[dnowacki-usgs]

Remove break line

[ssuttles-usgs]

made change