Hi John,
My responses inline below.
Andrew
----- Original Message -----
From: "John Caron" <ca...@unidata.ucar.edu>
To: <cf-metadata@cgd.ucar.edu>
Sent: Saturday, April 28, 2012 2:39 AM
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
Hi Andrew:
You can use a dimension=1 instead of a scalar.
OK, you mean if one used the vector method.
But you cant use
lat(lat)
lon(lon)
time(time)
the correct usage in the single profile case would be:
lat(profile)
lon(profile)
time(profile)
So, do you mean in the vector method have this? (simpler I guess to have common
profile dimension = 1)
dimensions:
profile=1
pressure = 57
variables:
lat(profile)
lon(profile)
time(profile)
pressure(pressure)
temperature(pressure)
Instead of this?
Dimensions:
time=1
lat=1
lon=1
pressure=57
Variables:
time(time)
lat(lat)
lon(lon)
pressure(pressure)
temperature(pressure)
John
On 4/27/2012 12:03 AM, andrew walsh wrote:
Hi John,
Thanks for your advice.
For a single vertical profile and single valued time, lat, long.
it seems there are two acceptable ways i.e 1 element vector or single valued
scalar.
Quoting from 'section 2.4 Dimensions' of CF standard:
1 element vector:
"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.
and in the next sentence a scalar:
"It is also acceptable to use a scalar coordinate variable which eliminates
the need for an associated size one dimension in the data variable."
1) ***Vector co-ordinate variables*******
Dimensions:
time=1
pressure=56
lat=1
lon=1
Variables:
time(time)
lat(lat)
lon(lon)
temperature(pressure)
2) **Scalar co-ordinate varaibles****
Dimensions:
pressure =56
Variables:
time
lat
lon
temperature(pressure)
The scalar approach you suggest as in section "H.3.3. Single profile" of the
CF v1.6 standard
is simpler than the vector approach so we will take your advice.
Regards,
Andrew
----- Original Message ----- From: "John Caron" <ca...@unidata.ucar.edu>
To: "andrew walsh" <awa...@metoc.gov.au>
Cc: <cf-metadata@cgd.ucar.edu>; "Luke Callcut" <l...@metoc.gov.au>;
<g...@metoc.gov.au>
Sent: Thursday, April 26, 2012 10:48 AM
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
Hi andrew:
The file you sent (20110818T001140Z_M_HI504BEN.nc) appears to be a single
profile. Assuming that, you would use the following template:
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8363696
note that lat, lon and time coordinates all have to be scalars.
John
On 4/18/2012 8:24 PM, andrew walsh wrote:
Hi John,
We have now constructed a real netCDF file for you to check. QC flag
variables have been added in. The QC flagging method is based on the
proposed IODE scheme in (1) below.
Attached are the sample .nc file, text (ncdump) of same and a document
specifying the CDL.
Thanks and Regards,
Andrew Walsh
Ref.
(1) Konovalov et. al (March 2012), Proposal to adopt a quality flag scheme
standard
for oceanographic and marine meteorological data, Version 1.2.
----- Original Message ----- From: "John Caron" <ca...@unidata.ucar.edu>
To: "andrew walsh" <awa...@metoc.gov.au>
Sent: Thursday, April 05, 2012 10:44 AM
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
ok
On 4/4/2012 6:42 PM, andrew walsh wrote:
Hi John,
Thank for your offer to check a sample netCDF CTD data file. At moment we
don't have
some real .nc file but when we do I can send you a file for checking.
Andrew
----- Original Message ----- From: John Caron
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, April 04, 2012 5:55 AM
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
Hi all:
Lets see, I havent followed the entire conversation, but:
1) Andrew if you can send me a sample file (not just the CDL) I can check
if it works in the CDM with the new 1.6 conventions, and maybe give you
some advice from my POV.
2) Aggregation in the CDM comes in 2 flavors. 1) The original
implementation simply appends multidimensional arrays together, eg
"joinNew " and "joinExisting" NCML aggregation. I call it "syntactic
aggregation" because it doesnt know what its aggregating, and the
homogeneity requirements are strict. 2) "Feature Type collections" (aka
"semantic aggregation") are the more recent development. These understand
the coordinate information of the data, and so can handle variations in
the representation, eg ragged arrays, scalar coordinates, etc. In this
case, the CDM understands a dataset as a collection of "features
objects", which can be stored in a collection of files. The interfaces
to these collections is still under development. Most current and future
work in the CDM is in this category.
John
snip ....
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata