⇐ ⇒

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

From: John Caron <caron>
Date: Fri, 27 Apr 2012 10:39:18 -0600

Hi Andrew:

You can use a dimension=1 instead of a scalar.

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)

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" <caron at unidata.ucar.edu>
> To: "andrew walsh" <awalsh at metoc.gov.au>
> Cc: <cf-metadata at cgd.ucar.edu>; "Luke Callcut" <luke at metoc.gov.au>;
> <greg at 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"
>>> <caron at unidata.ucar.edu>
>>> To: "andrew walsh" <awalsh at 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 at 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 at cgd.ucar.edu
>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>
>>>>
>>
>>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Apr 27 2012 - 10:39:18 BST

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

⇐ ⇒