Jonathan:
not to belabour , but in the interest of clarity, For GOES-R level 1 and 2 hemispheric products ...
there are non-existent points, at which the data vars have missing values and the aux coord vars have (syntactically) valid values.
note that placing (syntactically) valid values in the aux coord vars even though the data is missing is the simplest software design. I think we can accommodate a different approach if a change to the current CF conventions warranted it.
very respectfully,
randy
Randy C. Horne (rhorne at excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952-5100
url:
http://www.excaliburlabs.com
PGP Public Keys available at:
A HREF="
http://pgpkeys.mit.edu:11371">MIT's Key Server</A>
---------- Original Message ----------------------------------
From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
Date: Wed, 28 Mar 2012 13:26:42 +0100
>Dear all
>
>Brian has a good point that sect 5.3 allows that there might be missing data
>in aux coord variables. Appendix A - which is equally ancient in the story of
>CF :-) - is not consistent with this, because it didn't allow _FillValue or
>missing_value atts for coordinates until sect 9 was introduced in version 1.6.
>But never mind the history, the point is to clarify what we need now.
>
>In Randy's, Rich's and Bert's examples, if I understand correctly, there are
>non-existent points, at which both data and aux coord vars are missing values.
>That is also what sect 9 requires. I don't see any problem with this.
>
>Nan's example is different, because it has missing values in aux coord vars
>at points where there is non-missing data. If we all agree that this is OK
>too, then fine. Speaking for myself, I could agree to it, but I'm less happy,
>because clearly the aux coord var is not doing its job of locating the data.
>
>I think you said, Nan, that you might fill them in at some later stage. At
>that stage, they should certainly be aux coord vars. Before they are filled
>in, of course I am not saying they should be excluded from the file, but I
>am asking if they should be regarded as data, rather than coordinates. A
>pressure value which was destined to be an aux coord var, but is actually a
>data variable measured by a sensor and has missing values in it, could be
>named by the ancillary_variables attribute. It is really per-point metadata,
>which is what ancillary_variables are
>(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#ancillary-data)
>but you could argue it should not be regarded as an aux coord var if it can't
>provide information for every point where there is data.
>
>I'm just asking. I don't have a very strong opinion about this, but I'd like
>to know if others have the same concern that I do.
>
>My existing ticket (85) connected with this subject is a defect ticket. It
>is only able to correct mistakes. It can't make a substantive change to the
>convention, just clarify it. If we can decide easily how to clarify it, that
>is fine. I'll amend the ticket if we have a clear decision. Otherwise, we
>should use a different ticket.
>
>Best wishes
>
>Jonathan
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
..............End of Message ...............................-->
Received on Wed Mar 28 2012 - 06:38:41 BST
