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 <[email protected] > <mailto:[email protected]>> 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 > > [email protected] <mailto:[email protected]> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > _______________________________________________ > CF-metadata mailing list > [email protected] <mailto:[email protected]> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
