[CF-metadata] meaning of depth in the ocean

Jonathan Gregory j.m.gregory at reading.ac.uk
Thu Oct 28 09:59:24 MDT 2004


Dear Rich

> >I tend to think it is better to make the surface/geoid distinction even 
> >more
> >blatant by putting it in the standard name. 
> >
> Ok, that's fine.   I would just like to make sure that we allow  the 
> possibility of using a
> local datum for z=0 and specifying the offset between this local datum 
> and the geoid.
> This is important, since many people use local datums that are not the 
> geoid, and we don't want
> to break any of their software.  (we don't break anything if we only 
> *add* variables and attributes)
> 
> Here's another possible solution:  
> Just as we allow different units, origin and offset for time:
> (e.g.   units:"days since 1968-05-23 00:00:00 EST")
> 
> we could allow different units, origin and offset for height:
>         units:"meters above WGS84   -10.24"

I see what you mean. I don't think we can do exactly what you propose because
that units string doesn't comply with udunits so would break other software.
I agree that this is effectively an offset in the units, like the difference
between degC and K. udunits provides a syntax for specifying an offset but we
have disallowed it in CF.

In another thread we are discussing the introduction of a parameters attribute
to supply numbers which are used to define quantities when the standard_name
alone is not sufficient. We could have a standard_name of height_above_
geopotential_surface (more general than geoid) with parameters to specify the
the height of the geopotential surface above the geoid and to identify the
geoid/ellipsoid.

> I agree with you that the average of the free-surface is not the datum 
> (z=0).    I'm not
> sure I understand the issue, however.    This is why we want to be able 
> to specify the offset between the datum and some pedigreed geoid.

The issue is that when comparing a free-surface model simulation with altimetry
we would probably like heights wrt geoid i.e. subtract the area-average of zeta
uniformly from zeta. In other applications the model might like to output zeta
itself. Again, these are two different quantities (though only by a constant
offset, as you say). I think we agree we need to be able to distinguish them.

Cheers

Jonathan


More information about the CF-metadata mailing list