Hi all -
From a CDM developer perspective, an auxiliary coordinate is "just as
good" as a regular coordinate variable. The extra requirements on
coordinate variables are helpful in knowing when to optimize, eg
monotonicity allows one to efficiently find the index given the
coordinate value.
Are we reaching agreement that fill values are allowed in auxiliary
coordinate variables, aside from
In my understanding, we have always prohibiting missing data in aux
coord vars, and in section 9 we explicitly allowed for the first
time. Evidently we should be clear, one way or the other (which was
one of the intentions of the defect ticket I opened).
Should we be discussing this on the trac ticket? That would provide a
better trail - Mailman isn't very good if you're searching for a thread
like this - the subject doesn't mention coordinates.
Thanks -
Nan
On 3/26/2012 10:05 AM, Jim Biard wrote:
I am working with satellite data, and I, for example, have timestamps
that arrive in the data stream along with sensor measurements. I can
have independent missing values in both my time variable and my
measurement variables. I want to preserve all the incoming data, and
the restriction on "true" coordinate variables having no missing
values prevents me from designating my time variable as a coordinate
variable. If I want to represent the relationship between the time
variable and the measurement variables, the only recourse I have is
to designate the time variable as an auxiliary coordinate variable in
my measurement variables.
In the observational world, you cannot always be assured of meeting
all the restrictions imposed on "true" coordinate variables. In
fact, other restrictions imposed on coordinate variables might not be
met (monotonicity, for example), even though the contents of the
variable do function properly as coordinate information for another
variable. The only mechanism that I am aware of within CF to
document the relationship is the auxiliary coordinate attribute.
On Mon, Mar 26, 2012 at 11:20 AM, Nan Galbraith <[email protected]
<mailto:[email protected]>> wrote:
Hi Jonathan -
For underway CTD profiles (gliders and floats, too, I'd think) if
the pressure
sensor fails intermittently, you can approximate Z by
interpolating over
time, assuming there are good values along the track. In "final"
data, we might
do that, but we might like to present raw data in CF files, too.
So, yes, this data
would be useful, with fill values here and there in the pressure
record.
Are we getting into a grey area that might be outside the scope
of the CF
standard - judgements made about the usefulness of data?
Having all your
coordinates seems like an excellent NetCDF "best practice" and
could certainly
be a "rule" for many tools, but it could preempt the use of the
CF standard for
some kinds of observational data.
Cheers -
Nan
On 3/26/12 10:48 AM, Jonathan Gregory wrote:
Dear Nan and John
It's a good thing we're having this discussion! In my
understanding, we have
always prohibiting missing data in aux coord vars, and in
section 9 we
explicitly allowed for the first time. Evidently we should be
clear, one way
or the other (which was one of the intentions of the defect
ticket I opened).
The restriction on coord vars not having missing data is, I
think, hard to
avoid because they are required to be distinct and monotonic.
In Nan's case:
For something like towed CTD data, you might have a
period of time where
data from the pressure sensor is missing. If neither the
coordinate or aux
coordinate can contain null values, does this mean the
only options are
interpolating Z or removing that section of data?
When the sensor is missing, does that mean the data can't be
geolocated? As
you know, geolocation is one thing CF tries hard to do. Is
the data useful if
you don't know where it comes from? Perhaps you know in some
other way?
In John's case
Consider a geosynch satellite with lat/lon aux
coordinates. the
nature of the image is that there are many points around
the outside
of the image that are not located on the earth. i dont
see any good
choices other than to put missing values there for lat/lon..
Bert has coincidentally mentioned a similar case (not on the
list). I tend to
agree that if index space contains locations that simply do
not exist, you
could put missing data in aux coord vars, but I think this
needs a change to
the CF convention.
To add insult to injury, it seems possible that there are
valid data
values at these locations. Not sure about that however.
Can anyone
with geosynch data expertise comment?
As in Nan's case, I am curious about how the data can be
useful if it doesn't
have a location.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
*******************************************************
* Nan Galbraith Information Systems Specailist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 <tel:%28508%29%20289-2444> *
*******************************************************
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
[email protected] <mailto:[email protected]>
828-271-4900
_______________________________________________
CF-metadata mailing list
[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
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
