⇐ ⇒

[CF-metadata] water level with/without datum

From: olivier lauret <olauret>
Date: Mon, 1 Mar 2010 17:07:58 +0100

Hi all,

 

I think the use case sent by Roy is excellent and a little bit misleading at the same time: of course in his situation there is no need each time for a new standard name, if it is the same geophysical quantity that is estimated.

Or as a corollary, if I were Roy, I would put a different CF standard name only if it is a different temperature stored in the dataset.

Surface type (eg ocean, or river) is not always a criteria defining a specific geophysical quantity, it is only some kind of information for data location. Besides this information is also sometimes provided as flag values (like 0=river, 1=ocean etc.) in netCDF files.

 

Back to the the suite of "sea_surface_height_above_", I would personally militate for keeping them as they are, and adding new ones for lake+rivers..

Like "lake_surface_height_..", as the first proposal from Jonathan. (And perhaps something in the near future for ice sheets topography too, but it is not the priority now.)

 

Not because they are considering different surface types, but because they do not represent the same geophysical quantity, they are not processed using the same methods and assumptions (processes scales etc.). In my opinion that makes the difference, and that's why we need them.

And it is possible we do not need them in other situations, like we do not need to apply GRHSST definitions <http://www.ghrsst.org/SST-Definitions.html> using heights instead of temperature, do we?

 

Kind regards

 

Olivier.

 

 

-----Message d'origine-----
De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Seth McGinnis
Envoy? : samedi 27 f?vrier 2010 04:51
? : cf-metadata at cgd.ucar.edu
Objet : Re: [CF-metadata] water level with/without datum

 

>Therefore I think we have to decide what to call the new names. Roy suggested

>water body. As I've said before, I would prefer sea/lake/river_water (or with

>some other punctuation) to water_body_water, because sea/lake/river_water is

>more self-explanatory, and the repetition of "water" in water_body_water is

>clumsy and possibly confusing. I can imagine someone not being sure how to

>parse "water body water temperature" when they first come across it.

 

 

Instead of a prefix modifer, how about adding _body as a postfix

modifier?

 

So you could have sea_water_temperature for oceans and

water_body_temperature for oceans, rivers, lakes, and other

significant accumulations of liquid water.

 

Cheers,

 

----
Seth McGinnis
NARCCAP Data Manager
ISSE / ISP / IMAGe / CISL / NCAR
----
 
(P.S.: Observation/tangent: It seems like this conundrum may be arising in
part because the day-to-day meaning of the term "water" -- liquid H2O
-- is at odds with the definition given in the standard name
guidelines of "water in all phases if not otherwise qualified".  Were
there a blank slate, I would suggest using the unqualified term to
mean "liquid water", in better alignment with its commonsense meaning,
and coming up with a new term for the more restricted contexts where
one needs to refer to all three phases.  How frequently in current
usage does the "all phases" sense differ fom the usual sense? Would it
be worth considering a switch?  That would be an alternate way around
the issue of generic water bodies.)
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
 
 
                           Cliquez sur l'url suivante 
https://www.mailcontrol.com/sr/Y8JdOU4DsM7TndxI!oX7UvGHrMX8oTLhxXmnApiAmj9zdQJy4gJWXe3FyfcXLuoUBltZoDt4qRPbd8XIx2vetQ==  
                    si ce message est ind?sirable (pourriel).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100301/9268c33e/attachment-0002.html>
Received on Mon Mar 01 2010 - 09:07:58 GMT

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

⇐ ⇒