Dear All,
Couple of watchpoints.
(1) 'sea_water_pressure' currently carries no definition and is ambiguous. Does it mean the pressure exerted by the overlying water column or to the pressure exerted by the overlying water column plus atmopshere. The difference between the two is equivalent to a z co-ordinate shift of about 10 metres. The issue is clouded because virtually all CTD pressure sensors are calibrated to read zero in air, but isn't always the case for pressure sensors on moored instruments.
I have always assumed that the CF name referred to 'pressure exerted by sea water' (zero at sea level). Unless anyone has a different understanding might I suggest that we add a definition to remove this ambiguity? It becomes particulary important for Rick's application.
(2) I've been caused all kinds of problems in the past due to confusion between pressure as a z co-ordinate on a CTD and pressure as the measured variable on bottom pressure recorder. I have a feeling that this may not be an issue for CF, but thought I'd flag it in case. I'm not a CF power user so forgive me if it seems naiive.
Now for the issue of whether we need more standard names.
I like John's idea of having a 'pressure' variable to label sensor output, but would like his view on how we should define it in view of issue (1) above.
I can understand Rick's point that the salt water is denser than fresh and therefore the depth related to a given pressure is different (by something like 3% of the absolute depth). My worry as always is the difficulty I have deciding how to handle standard name labelling with datasets like a Humber Estuary axial CTD transect which starts at salinity 34 in the North Sea, reaches zero by Trent Falls and can have a 20 PSU surface to bed gradient on some of the profiles in between. If the 3% z co-ordinate error is significant to Rick's application then he might be better using a density profile constructed using the T/S data from the actual profile.
Incidentally, I the issue of what generic term to use for puddles/ponds/lakes/rivers/seas/oceans came up at a recent ontology workshop in and the reasoning went along the lines;
water column - implies quality spatial coverage is all z at a given x,y
water body - implies quality spatial coverage is all x.y.z
water body sample (or water body water) - implies quality spatial coverage is point x.y.z [what we need?]
Cheers, Roy.
>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 2/25/2008 8:22 am >>>
Dear Rich and John
Your discussion has raised again, in a different context, the need for a term
meaning "sea, lake or river", which we have struggled with in another thread on
the email list, to avoid having to introduce separate parallel standard names.
Not all lakes are fresh, so fresh_water would not be quite right.
I think there's another issue in your discussion, which is that you want to
give a name to the measurement given by a sensor, possibly without reference to
the geophysical significance of that measurement viz just "pressure", which
might be in air or in water. Most standard names are for geophysical quantities
since CF was set up to supply metadata for geophysical datasets. However we
have got some others like this, such as the coordinates of a measurement
platform. I would suggest making it clear that the quantity is not geophysical
by giving it a standard name such as sensor_pressure or pressure_measured_by_
sensor. What do you think?
Cheers
Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Mon Feb 25 2008 - 02:00:28 GMT
