Dear all,
For CMIP5 we will store for a few models the depth of ocean layers below
the geoid. Currently there is no standard_name for this quantity,
although there are other standard names of some relevance:
sea_floor_depth_below_geoid (alias: sea_floor_depth)
sea_surface_height_above_geoid
depth (described as "depth is the vertical distance below the surface)
and many other names including the term "depth", but always meaning
"below the surface", not "below the geoid".
I therefore propose "depth_below_geoid" as a new standard name, which
would differ from "depth" in that it is relative to the geoid rather
than the local surface.
Best regards,
Karl
On 1/4/11 3:40 AM, Jonathan Gregory wrote:
> Dear all
>
> In standard names I think CF has generally followed Roy's no (2):
>
>> 1) Create an idealised model with everything normalised and harmonised to the nth degree, declare it as a standard and force everybody to conform.
>> 2) Accept community practice but make sure that everything is unambiguously described. Interoperability then comes through the development of semantic resources describing the relationships between the descriptions.
> That is, we try to describe what people actually use, rather than force them
> to use a particular thing. Doing the latter may not work and in the end means
> the standard is not adopted. That is why we have standard names for quantities
> which could be interconverted. On the other hand, in CF in general we also try
> to discourage unnecessary proliferation of choices, by not introducing new
> mechanisms if we already have ones that would serve a new purpose.
>
> I agree that a general mask would be a good way forward, but land/sea is such
> a common case, which we already support, that I think we should continue to
> support it. But we could also introduce a standard name for a general type
> mask, as Steve suggests. A data variable containing a mask with this standard
> name should have a string-valued scalar coordinate variable with standard name
> of area_type to specify it further. This is consistent with the idea behind
> introducing the area_type, which allows us to describe quantities that depend
> on area type without providing specific standard names for them.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110104/75d66c3c/attachment-0001.html>
Received on Tue Jan 04 2011 - 14:24:49 GMT
