Rich Signell wrote:
> Jonathan Gregory wrote:
>
>> This problem is broader than dimensionless coordinates. The basic
>> problem is
>> what "depth" means as a vertical coordinate in the ocean or the ocean
>> model. At present we have a standard_name of depth, defined relative
>> to the
>> surface, which is further defined as mean sea level.
>>
> I just got off the phone with John Wilkin, another ocean modeler, and
> he reminded me
> that mean sea level should *not* be thought of as the local
> geopotential for ocean models.
> Consider the Gulf Stream region, where there is a jump in mean sea
> level of order 1 meter!
>
>> But...
>>
>> - it might be relative to the geoid or some other geopotential
>> surface, instead
>> of mean sea level, so perhaps we should have separate standard names for
>> depth_below_geoid and depth_below_surface.
>>
>>
>>
> We could have differing standard names, or we could just say that
> depth is defined
> relative to "the datum" and have a "datum_offset" field that contains the
> offset between "the datum" and the geoid.
>
>> - what does it mean for an ocean model? So far (e.g. for the IPCC data
>> collection) we have been assuming that in a rigid-lid model, "geoid"
>> means
>> the rigid lid z=0. What does z=0 mean in an ocean model with a free
>> surface?
>>
>>
>>
> z=0 means the same thing whether free surface or rigid lid.
> In free surface models, there is a variable (e.g. "zeta") that
> represents the departure
> of the free surface from the "datum" (z=0).
>
>>> What do you think about adding to the CF convention the
>>> specification of a 2D variable
>>> (function of lat, lon) called "geoid_offset" (or equivalent) that
>>> would specify the
>>> offset between the "local datum" (z=0) and the geoid?
>>>
>>
>>
>> If the local datum is a geopotential, a single number rather than a
>> field ought
>> to be enough to specify the offset, shouldn't it?
>>
>>
> Hmmm... perhaps you are right. I was thinking before that we might
> want to specify the
> datum relative to mean sea level, which would technically require a 2D
> offset field, but in light of
> John Wilkin's point, I can't actually think of any cases where this
> would make sense.
>
>>
>>
>>> And while we are on the subject, are we being intentionally
>>> ambiguous by referring
>>> to "the geoid"? I'm thinking about NAD27, GRS80, WGS84, etc..
>>>
>>
>>
>> Yes, we are being vague. In some cases e.g. ocean models for climate,
>> this
>> doesn't matter. But sometimes it clearly would matter. So we may need
>> some
>> further way to specify the geoid, as one of the reference ellipsoids.
>>
>>
> Yes, why not list the reference ellipsoid. For the cases where it
> will matter people will
> be sure to specify the correct ellipsoid, and for all the other cases,
> it just won't matter.
>
> -Rich
>
> - Richard P. Signell rsignell at usgs.gov
> U.S. Geological Survey Phone: (508) 457-2229
> 384 Woods Hole Road Fax: (508) 457-2310
> Woods Hole, MA 02543-1598
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Im sure you all know that the GIS community has been wrestling with this
level of detail for a while, although likely a lot of concepts from
modelers will be new. At Unidata we have been closely following the OGC
specs, with an eye to using them and extending when needed. I think the
BADC folks know about this in more detail. Can we start from OGC
definitions and see what needs to be added, then create CF conventions
for them ?
Received on Tue Oct 26 2004 - 10:40:19 BST
