[CF-metadata] CF-1.6 Conformance Requirements/Recommendations

John Caron caron at unidata.ucar.edu
Mon Mar 26 10:09:50 MDT 2012

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.


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 <ngalbraith at whoi.edu 
> <mailto:ngalbraith at whoi.edu>> 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
>         CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>         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
>     CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>     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
> jim.biard at noaa.gov <mailto:jim.biard at noaa.gov>
> 828-271-4900
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120326/82485c28/attachment-0001.html>

More information about the CF-metadata mailing list