Stephan,
You are exactly right that the only way provided by CF to indicate that
a group of coordinate variables (both 'true' and auxiliary) and
coordinate reference system (CRS) spec compose a set (or whatever name
you wish to call it) that should be treated as a unit is to to have them
all referenced by a data variable. I think this isn't such a great idea,
but it is what it is.
One way to do this within CF is to create a scalar variable that lists
all of the coordinates of both types in a coordinates attribute and
identifies the CRS in a grid_mapping attribute. The variable serves only
to indicate that these all compose a set.
Grace and peace,
Jim
On 10/14/14, 1:07 PM, Seth McGinnis wrote:
> Hi Stephan,
>
> I think you'll run into trouble with surface variables that have
> different reference heights -- like 10-meter winds vs 2-meter air
> temperature or 500-mb height. Those will have the same dimensionality
> but different auxiliary coordinates. (Especially if you specify height
> using a scalar coordinate, in which case they'll also have the same
> dimensions as a purely 2-D surface variable like precipitation or skin
> temperature.)
>
> Cheers,
>
> --Seth
>
>
>
> On 10/13/14 12:30 PM, Stephan Hoyer wrote:
>> Hi Seth,
>>
>> So in my Python library for working with netCDF-like data [1],
>> coordinates are a property of the dataset, rather than being associated
>> with particular data variables. Within this context, it is possible to
>> have a dataset that only contains coordinates. I agree that such a
>> dataset is not terribly useful on its own (although we have indeed used
>> them as templates in the past), but I like to cover all the edge cases
>> in my code :).
>>
>> I think it would be reasonable for CF conventions to handle the
>> possibility of auxiliary coordinates associated with an entire dataset.
>> It's straightforward to implicitly associate auxiliary coordinates with
>> data variables based on shared dimensions. I can't think of any case
>> where I would not want to automatically associate all dimension
>> compatible auxiliary coordinates to a data variable, but I may be
>> missing something.
>>
>> In truth, I suppose it doesn't matter that much if other libraries
>> reading the file consider lat & lon to be coordinates or not. I just
>> want to be able to ensure that my own library can faithfully
>> serialize/deserialize these datasets, and ideally, I could do that
>> according to more general conventions. My library already does not
>> strictly enforce the CF data model (it takes a more practical bent), but
>> this is the first time I would need to come up with storage conventions
>> of my own.
>>
>> Thanks,
>> Stephan
>>
>> [1] https://github.com/xray/xray
>>
>> On Mon, Oct 13, 2014 at 10:52 AM, Seth McGinnis <mcginnis at ucar.edu
>> <mailto:mcginnis at ucar.edu>> wrote:
>>
>> Hi Stephan,
>>
>> My understanding is that the CF point of view would be that if you don't
>> have a data variable, you can't have auxiliary coordinates.
>>
>> In my experience, if your file only contains 2D lat and lon, it's
>> because you want to work with them as data variables, not because
>> they're coordinates for something absent from the file. (That, or it's
>> some kind of template or fractional file that you plan to add on to
>> another file, but in that case I don't expect the file to be meaningful
>> or conformant on its own.)
>>
>> Can you say a bit about why any libraries that read the file should
>> always consider lat & lon to be coordinates? It might work to check the
>> standard_name or the units, instead of looking for a coordinates
>> attribute.
>>
>> Cheers,
>>
>> --Seth
>>
>>
>> On 10/12/14 1:14 AM, Stephan Hoyer wrote:
>> > In the process of writing a routine to faithfully serialize data
>> > according to CF conventions, I have encountered a conundrum.
>> >
>> > Suppose I have a would like to save a netCDF file representing a
>> spatial
>> > grid, with 1D variables "x" and "y" and 2D variables "latitude" and
>> > "longitude". All of these variables should be considered
>> coordinates by
>> > any libraries that read the file, and I would like to indicate this in
>> > the netCDF file.
>> >
>> > If there was an additional 2D data variable (e.g., "temperature"), I
>> > could indicate that latitude and longitude are coordinates by adding
>> > them to the "coordinates" attribute on the "temperature" variable.
>> > However, I have no such variable here.
>> >
>> > Is there any standard way I can indicate that these variables are
>> > coordinates if there are no non-coordinates on which to add the
>> > appropriate attribute? I am considering considering using a global
>> > "coordinates" attribute but that is definitely outside the CF spec.
>> >
>> > Thanks,
>> > Stephan
>> >
>> >
>> > _______________________________________________
>> > CF-metadata mailing list
>> > CF-metadata at cgd.ucar.edu <mailto: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 <mailto: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
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141015/8f5bd7a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beaagifc.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141015/8f5bd7a0/attachment-0001.png>
Received on Wed Oct 15 2014 - 10:31:30 BST
