Hello Nan, > For our meteorology time series data, we have singleton latitude and > longitude, unlimited > time, and numerous sensor heights. We provide time as a dimension > and the others as > scalar coordinates. I don't think we would gain clarity by creating > a height dimension > for each instrument's Z position. Our data is really a 1 > dimensional array where the > Z coordinate is slightly different for each variable, and that's > what we code it as.
If I understand your use case correctly, I'd put a slightly different emphasis on the interpretation. I'll try to explain ... The data were created with a logical dimensionality which should, I believe, should be recorded in the file. This not restrictive, however, since having read the file in, software can easily choose to redistribute any size 1 (scalar or 1-dimensional) coordinates as it sees fit. My preference is that each scalar coordinate corresponds to a different logical dimension which has been omitted from the array and file for clarity. Currently, CF-netCDF has no means of binding (a subset of) these scalar coordinates to the same dimension - if that's what you want then they be converted to size 1, 1 dimensional coordinates for a named size 1 dimension which exists in the array. This case may be slightly cumbersome for file storage, but it is unambiguous and also allows the common case of one-scalar-coordinate-per-logical-dimension to be very easy and clear to encode. To your example: I would say that your *data* is logically 4 dimensionsal because in the context of a measuring instrument, I think that time, lat, lon, and height are all logically orthogonal. However, that's a pain to encode in a file and also to use interactively so CF-netCDF provides a mechanism which allows you to store a 1 dimensional *array* to make everyone's lives easier. Imagine if you had multiple timeseries for a particular sensor at a particular height, at each location on rectangular lat/lon grid. Then you might want to aggregate them to make 3 dimensionsal *array* (time/lat/lon) which is still logically 4 dimensional. It seems to me that this operation is something that you might encourage with such variables, because the 3-d array contains exactly the same information as its constituent 1-d arrays. Thus, deep down, everything is logically 4-d and I would say that the files which you have described and created say that very clearly to me! All the best, David -- David Hassell National Centre for Atmospheric Science (NCAS) Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K. Tel : +44 118 3785613 E-mail: [email protected] _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
