⇐ ⇒

[CF-metadata] Ocean CTD data following CF Conventions v1.6

From: Nan Galbraith <ngalbraith>
Date: Tue, 03 Apr 2012 09:27:26 -0400

Hi Andrew -
> I am not sure if I should have TEMPERATURE and SALINITY arrays with 4
> dimensions
> like TEMPERATURE(TIME,LATITUDE,LONGITUDE,PRESSURE) or just 1 dimension
> like I have above i.e. TEMPERATURE(PRESSURE). ?

While we don't store profile data in OceanSITES, we are working on our
coordinates
to make them conform more to published standards, so I've been reading
the docs
on this lately. So, it's fresh in my mind - fresh, if not exactly clear.

The NetCDF Best Practices page
(unidata.ucar.edu/software/netcdf/docs/BestPractices.html)
recommends:
> Make coordinate variables for every dimension possible (except for
> string length dimensions).
And the CF manual has this recommendation about the order of the coordinates
and the use of scalar coordinates as dimensions, in section 2.4:

> If any or all of the dimensions of a variable have the interpretations
> of "date or time" (|T|), "height or depth" (|Z|), "latitude" (|Y|), or
> "longitude" (|X|) then we recommend, but do not require (see
> Section 1.4, "Relationship to the COARDS Conventions"
> <http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#coards-relationship>),
> those dimensions to appear in the relative order |T|, then |Z|, then
> |Y|, then |X| in the CDL definition corresponding to the file. All
> other dimensions should, whenever possible, be placed to the left of
> the spatiotemporal dimensions.
>
> Dimensions may be of any size, including unity. When a single value of
> some coordinate applies to all the values in a variable, the
> recommended means of attaching this information to the variable is by
> use of a dimension of size unity with a one-element coordinate variable.
>

These 2 recommendations would lead me to suggest that, *IF* your
pressure is
monotonic, you'd want to use:
TEMPERATURE(TIME,PRESSURE,LATITUDE,LONGITUDE)

If your pressure isn't monotonic, and so can't be a coordinate variable,
I don't know
whether it's preferable to demote ALL the coordinates to auxiliary
coordinate variable
status,
TEMPERATURE: coordinates = "TIME,PRESSURE,LATITUDE,LONGITUDE" ;

Cheers -
Nan

On 4/3/12 1:15 AM, andrew walsh wrote:
> Hi Roy/All,
>
> Agree totally it would be good to get this CTD netCDF done in an
> interoperable way.
>
> Regarding having pressure vs. depth. We liked to use pressure because:
>
> 1) It is the thing that is measured, let us store just that and
> calculate depth if needed.
>
> 2) Depth can later be easily be calculated on the fly
> using the 'Pressure to Depth' algorithm in "UNESCO (1983) Techinical
> Papers in Marine Science 44, Algorithms for Computation of fundamental
> properties
> of Seawater. One can use the python seawater library (see
> http://packages.python.org/seawater/ )
> and seawater.csiro.depth(p, lat) to get depth from pressure and
> seawater.csiro.pres(depth, lat)
> to get pressure from depth.
>
> 3) I noted that the ARGO project (10000's CTD like profiles) and
> others like
> CSIRO Oceanography in Aust. make data available with just pressure.
>
> 4) It makes our processing and QC a whole lot simpler. We don't
> have to worry about calculating and managing the extra 'depth' variable.
>
> Is there any problem with having the "pressure" as a co-ordinate
> which isn't really a "dimensional"
> quantity like depth (z) in the 4-D sense i.e x,y,z,t ?
>
> However I note that pressure (decibar) is allowed as a vertical axis
> e.g see section
> 4.3. Vertical (Height or Depth) Coordinate of CF v1.6 conventions
> document which says:
>
> "A vertical coordinate will be identifiable by:
>
> . units of pressure; or
> . the presence of the positive attribute with a value of up or down
> (case insensitive).
> "
>
> AND
>
> section 4.3.1. "Dimensional Vertical Coordinate" which says:
>
> "The units attribute for dimensional coordinates will be a string
> formatted as per the udunits.dat3 file. The
> acceptable units for vertical (depth or height) coordinate variables are:
>
> . units of pressure as listed in the file udunits.dat. For vertical
> axes the most commonly used of these include
> include bar, millibar, decibar, atmosphere (atm), pascal (Pa), and hPa.
> ...
> ..."?
>
>
> Regards,
>
> Andrew
>
> ----- Original Message ----- From: Lowry, Roy K.
> To: andrew walsh
> Cc: Jim Biard ; Upendra Dadi ; cf-metadata at cgd.ucar.edu ; Luke Callcut
> ; greg at metoc.gov.au ; sdn2-tech at seadatanet.org
> Sent: Tuesday, April 03, 2012 2:16 PM
> Subject: RE: [CF-metadata] Ocean CTD data following CF Conventions v1.6
>
>
> Hi Andrew,
>
> SeaDataNet will very soon be considering how it is going to encode
> data, including single CTD casts, in CF-compliant NetCDF and so I
> think the time is ripe for agreeing how the significant numbers of us
> who indulge in this practice for whatever reason do it. That way
> we'll end up with interoperable data.
>
> I think there are a number of people on this list who have already
> encoded single CTDs into NetCDF and so it would be useful to start by
> asking for descriptions (like Andrew's examples) of how this has been
> done and what tools are dependent upon that encoding.
>
> The z co-ordinate parameter (pressure/depth) is also an issue worth
> resolving. Whilst interconversions are relatively straightforward,
> agreement would make life much easier. My preference leans dowards
> having depth as the dimension with pressure as an optional variable.
> That way we interoperate with other kinds of oceanographic profile
> data such as bottle data.
>
> If we can get that far, we can then look at how to aggregate multiple
> CTDs into a file according to the CF point data conventions.
>
> Cheers, Roy.
>
>
> From: andrew walsh [awalsh at metoc.gov.au]
> Sent: 03 April 2012 04:39
> To: Lowry, Roy K.
> Cc: Jim Biard; Upendra Dadi; cf-metadata at cgd.ucar.edu; Luke Callcut;
> greg at metoc.gov.au
> Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
>
>
> Hello Roy, Upendra, Jim and CF list,
>
> Thanks for all your feedbacks.
> My proposal relates to single CTD profile data (a vertical profile of
> pressure, Temp. Salinity)
> not a trajectory in x,y,z,t and I have put :featureType = "profile" as
> recommended in the global
> attributes section. As Roy has mentioned to Jim CTD data is usually
> processed and QC'ed
> as a single profile per netCDF file so that's why I am doing it this way.
>
> Aggregations using multiple CTD profiles per netCDF file
> may be constructed later at say national/international data centres
> and these aggregrations
> would follow the CF conventions v1.6, Chapter 9 - Discrete Sampling
> geometries
> and also the new netCDF templates provided by NODC, thanks NODC -:)
>
> Roy,
>
> The recent NODC netCDF templates don't have an aggregation example for
> CTD
> however the "Profile/World Ocean Database Observed Level" example
> comes close
> (see http://www.nodc.noaa.gov/data/formats/netcdf/) and click on
> Profile/World Ocean Database Observed Level link. This example appears
> to be for ocean station/bottle samples with vertical dimension of
> depth (z) (m) rather
> than case of CTD which would use pressure (dbar) as the vertical (z)
> dimension.
> It would be useful I think to have a NODC netCDF template for an
> aggregation of
> CTD casts.
>
> Upendra,
>
> Based on your responses and what I have seen at NODC and other places
> it seems there are 2 methods to do this:
>
> 1) You can have dimensions for lat, long time i.e an array
> with a single value. That is:
>
> dimensions:
> TIME=1
> PRESSURE=729
> LATITUDE=1
> LONGITUDE=1
>
> variables:
>
> double TIME(TIME) ;
> + std. attrs.
> double LATITUDE(LATITUDE) ;
> + std. attrs.
> double LONGITUDE(LONGITUDE) ;
> + std. attrs.
> double PRESSURE(PRESSURE) ;
> + std. attrs.
>
> double TEMPERATURE(PRESSURE) ;
> + std. attrs.
> TEMPERATURE:coordinates="TIME LATITUDE LONGITUDE PRESSURE"
>
> double SALINITY(PRESSURE) ;
> + std. attrs.
> SALINITY:coordinates="TIME LATITUDE LONGITUDE PRESSURE"
>
> (2) Other way is to have Lat, long and time are single valued scalars:
>
> dimensions:
>
> PRESSURE=729
>
> variables:
>
> double LATITUDE ;
> + std attrs
>
> double LONGITUDE ;
> + std attrs
>
> double TIME ;
> +std attrs
>
> double PRESSURE(PRESSURE) ;
> + std. attrs.
>
> double TEMPERATURE(PRESSURE) ;
> + std. attrs.
> TEMPERATURE:coordinates="TIME LATITUDE LONGITUDE PRESSURE"
>
> double SALINITY(PRESSURE) ;
> + std. attrs.
> SALINITY:coordinates="TIME LATITUDE LONGITUDE PRESSURE"
>
> I can see Method 2 above is much simpler and I would prefer to use
> this.
>
> However I have another small concern about all of this. Given there is
> more than
> 1 way to treat dimensions does the netCDF plotting and visualising
> sofware out
> there understand both approaches. That is can we expect something like
> ncBrowse, IDV or ODV? give me a plot of say salinity vs. pressure
> and work OK with BOTH approaches to coding the netCDF?
>
> Thanks and Regards All,
>
> Andrew Walsh
> ----- Original Message ----- From: Lowry, Roy K.
> To: Upendra Dadi ; andrew walsh
> Cc: Luke Callcut ; cf-metadata at cgd.ucar.edu ; sdn2-tech at seadatanet.org
> Sent: Tuesday, April 03, 2012 9:31 AM
> Subject: RE: [CF-metadata] Ocean CTD data following CF Conventions v1.6
>
>
> Hi Upendra,
>
> I like the idea of a station dimension. It goes a long way to
> resolving the issue raised in my response to Jim which was based on
> the tunnel vision of having pressure/depth as a dimension. I have yet
> to look at the recently published NODC NetCDF templates. Is this CTD
> encoding included in them? If so, I'll bump up looking at them on my
> 'todo' list. I'd also recommend that Andrew and my colleagues in
> SeaDataNet take a look.
>
> Cheers, Roy.
>
> From: cf-metadata-bounces at cgd.ucar.edu
> [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Upendra Dadi
> [upendra.dadi at noaa.gov]
> Sent: 02 April 2012 17:21
> To: andrew walsh
> Cc: Luke Callcut; cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
>
>
> Hi Andrew,
> Either way it should be okay as far as CF compliance is concerned.
> But the dimensions - latitude, longitude and time are not really
> required. If it is required to indicate that there is only one
> station(profile) in the file, there could be a dimension for number of
> stations instead, with a value of 1. Also, using a station dimension
> is the way to go if storing a collection of profiles in a single file.
> Here at NODC, we took the approach that we would use the same
> consistent representation whether there is a single instance or a
> collection in a file.
>
> Upendra
>
> On Mon, Apr 2, 2012 at 2:51 AM, andrew walsh <awalsh at metoc.gov.au> wrote:
>
> Hi CF lis
> We are working on coding up some 1000's netCDF files off CTD
> instruments and want to make usre we are following the
> latest netCDF conventions (v1.6) OK. As background the CTD records
> a profile pressure, temperature and salinity.
>
> Here is a summarised CDL version (not all attributes+variables+qc
> flags there, just majors for now)
> of what we propose:
>
> dimensions:
> TIME=1
> PRESSURE=729
> LATITUDE=1
> LONGITUDE=1
>
> variables:
> double TIME(TIME) ;
> TIME:standard_name = "time" ;
> TIME:units = "days since 1950-01-01 00:00:00Z" ;
> TIME:axis = "T" ;
> TIME:valid_min = 0. ;
> TIME:valid_max = 999999. ;
>
> double LATITUDE(LATITUDE) ;
> LATITUDE:standard_name = "latitude" ;
> LATITUDE:units = "degrees_north" ;
> LATITUDE:axis = "Y" ;
> LATITUDE:valid_min = -90. ;
> LATITUDE:valid_max = 90. ;
>
> double LONGITUDE(LONGITUDE) ;
> LONGITUDE:standard_name = "longitude" ;
> LONGITUDE:units = "degrees_east" ;
> LONGITUDE:axis = "X" ;
> LONGITUDE:valid_min = -180. ;
> LONGITUDE:valid_max = 180. ;
>
> double PRESSURE(PRESSURE) ;
> PRESSURE:standard_name = "sea_water_pressure" ;
> PRESSURE:units = "decibars" ;
> PRESSURE:axis = "Z" ;
> PRESSURE:valid_min = 0. ;
> PRESSURE:valid_max = 12000. ;
> PRESSURE:positive = "down" ;
>
> double TEMPERATURE(PRESSURE) ;
> TEMPERATURE:standard_name = "sea_water_temperature" ;
> TEMPERATURE:units = "degrees_C" ;
> TEMPERATURE:_FillValue = -99.99 ;
> TEMPERATURE:valid_min = -2. ;
> TEMPERATURE:valid_max = 40. ;
> TEMPERATURE:coordinates="TIME LATITUDE LONGITUDE PRESSURE"
>
> double SALINITY(PRESSURE) ;
> SALINITY:standard_name = "sea_water_salinity" ;
> SALINITY:units = "psu" ;
> SALINITY:_FillValue = -99.99 ;
> SALINITY:valid_min = 0. ;
> SALINITY:valid_max = 40. ;
> SALINITY:coordinates="TIME LATITUDE LONGITUDE PRESSURE"
>
> // global attributes:
> :conventions = "CF-1.6" ;
> :featureType = "profile"
> :cdm_data_type = "profile"
> + several other attributes later for ISO19115 metadata generation
>
> I am not sure if I should have TEMPERATURE and SALINITY arrays with 4
> dimensions
> like TEMPERATURE(TIME,LATITUDE,LONGITUDE,PRESSURE) or just 1 dimension
> like I have above i.e. TEMPERATURE(PRESSURE). ?
>
> Any feedback on the above is greatly appreciated.
>
> Andrew Walsh
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>


-- 
*******************************************************
* Nan Galbraith        Information Systems Specailist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120403/5c33e064/attachment-0001.html>
Received on Tue Apr 03 2012 - 07:27:26 BST

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

⇐ ⇒