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
>
>
Received on Tue Oct 14 2014 - 11:07:03 BST
