⇐ ⇒

[CF-metadata] Auxiliary coordinates without associated data variables

From: Stephan Hoyer <shoyer>
Date: Mon, 13 Oct 2014 11:30:18 -0700

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> 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141013/35383fa7/attachment-0001.html>
Received on Mon Oct 13 2014 - 12:30:18 BST

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

⇐ ⇒