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: d.c.hassell at reading.ac.uk
Received on Thu May 23 2013 - 15:44:01 BST
