⇐ ⇒

[CF-metadata] fixed sensors, depth, datum

From: Ethan Davis <edavis>
Date: Mon, 29 Sep 2008 16:01:50 -0600

Hi Jon, Jonathan, all,

I definitely agree with Jon that this is a head-scratcher.

I also finally understand what Jonathan means by distinct geophysical
quantities in this case. And agree that height above a geoid and height
above a reference ellipsoid are distinct geophysical quantities. (Sorry
it took so long for me to understand.)

It seems there are two important characteristics that need capturing:
1) the geophysical significance of a vertical CRS (height, altitude,
pressure, sigma, etc), and
2) the details of a vertical CRS, possibly enough to enable
intercomparison with data on a different vertical CRS.

The first seems appropriate to capture in the standard name attribute as
Jonathan has been suggesting. However, I am still a bit concerned about
the proliferation of standard names. I'm not sure if tidal or station
vertical datum should be marked as height_above_geoid and I don't know
vertical datum well enough to know how many other types there are in
common use.

As the second could be fairly complicated, it seems best captured in a
vertical crs variable (similar to a grid mapping variable). Which would
also allow files to contain data on multiple vertical CRS (just as files
can now contain multiple horizontal CRS/grid mappings). This also seems
likely to allow CF to capture vertical datum transformation/offset
information if desired. Then again, I'm not sure the relationship
between vertical coordinate variables and auxiliary coordinate variables
is as clean as it is with grid mappings.

Ethan

Jon Blower wrote:
> Dear Jonathan and Ethan (et al),
>
> Definitely a head-scratcher, this one. My own view (which may well
> change!) is as follows:
>
> - If we were concerned only with data expressed as discrete vertical
> profiles then I would tend to agree with Ethan (the distinction is
> just a vertical coordinate transformation).
>
> - However, given that we are primarily concerned with 3D fields I
> think that the quantities are distinct (agreeing with Jonathan). A
> x-y slice through the field has a specific geophysical meaning if the
> vertical coordinate is height_above_geoid, but it has no particular
> geophysical meaning if the vertical coordinate is
> height_above_ellipsoid.
>
> Two points to muddy the waters further:
>
> - Being pedantic, two points at the same height above the geoid might
> not have quite the same potential energy. The 3D geopotential
> contours are not everywhere equally-spaced. However, I imagine this
> is not usually a large effect, unless the data in question are close
> to a large gravity anomaly.
>
> - Vertical coordinate values (heights, altitudes etc) are often
> inferred from other quantities (esp. pressure in both air and water).
> Since CF is expanding to include in situ data, can we express this
> somehow, so that users know that the coordinate value depends on
> certain assumptions?
>
> Cheers, Jon
>
> On Mon, Sep 29, 2008 at 9:10 AM, Jonathan Gregory
> <j.m.gregory at reading.ac.uk> wrote:
>
>> Dear Ethan
>>
>> I agree that different definitions of the reference ellipsoid do not constitute
>> different geophysical quantities. Likewise different definitions of the geoid
>> all give the same geophysical quantity. Therefore I agree that the geoid should
>> be identified as part of the CRS (naming it in the grid_mapping would be
>> convenient), just as the ellipsoid is identified as part of the CRS (we added
>> the parameters specifying the ellipsoid to the grid_mapping as part of Phil
>> Bentley's change to the conventions). I agree too that the definition of the
>> vertical CRS is relevant both to coordinate variables and data variables. That
>> is another reason why it would make sense to put it in the grid_mapping.
>>
>> I do not agree that the geoid and the ellipsoid are geophysically equivalent.
>> It is quite likely that you might want to have data variables in the same file
>> for both height above geoid and height above ellipsoid, just as you might also
>> want to have height above the surface and height above mean sea level. These
>> are all heights wrt to surfaces which are defined as a function of lat and lon.
>> All of these surfaces therefore depend on the horizontal CRS, as you say. But
>> these surfaces are all geophysically distinct. The reference ellipsoid is
>> "just" a matter of definition, but the others (geoid, surface = bottom of atmos
>> and mean sea level) are not matters of definition: they are complicated facts
>> about the real world that have to be measured. Wikipedia says
>> "The geoid surface is irregular, unlike the reference ellipsoids often used to
>> approximate the shape of the physical Earth, but considerably smoother than
>> Earth's physical surface."
>>
>> These surfaces have different physical meanings. For instance, surfaces with
>> constant height above the geoid (geopotential surfaces) are those on which
>> there is zero gravitational/centrifugal force; this not true of other surfaces.
>> Height above these various surfaces has different geophysical meaning. You
>> would not want to replace height above geoid with height above ellipsoid by
>> changing the definition of the CRS. They should remain distinct quantities,
>> regardless of the definition of geoid and ellipsoid in the CRS. Hence I think
>> they need different standard names.
>>
>> Best wishes
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>
>
>
>

-- 
Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis at ucar.edu
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
Received on Mon Sep 29 2008 - 16:01:50 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒