My previous email might have been blocked so here it is again:
Dear all,
I support the first paragraph, but concerning the last paragraph below, I would suggest being more explicit about the difference between a data "void" and simply when there is "no valid data for an element". Also do the rules given in that paragraph apply only to "Representations of collections of features in data variables"?
As written, it seems like someone reading this paragraph wouldn't know what to do when they were working with a dataset, which was a function of latitude and height in meters with an auxiliary coordinate of say height in feet. Suppose all the data were missing at one height. If "missing data" implies "missing auxiliary coordinate value", as a read the current text, then you would be required to keep the height in meters (the coordinate), but indicate "missing" for the height in feet (the auxiliary coordinate). Also, what is one to do if it is missing only a one latitude?
Is this what is called for? Does it make sense? I would vote no to the 2nd question.
regards,
Karl
On 4/2/12 3:03 PM, Karl Taylor wrote:
> HI all,
>
> following my previous email. I think the rules for discussed in ticket 85 should apply only to discrete sampling geometries.
>
> Karl
>
> On 4/2/12 1:00 PM, Jonathan Gregory wrote:
>
> Dear all
>
> Thanks for your postings. There seems to be a consensus on this. I have
> therefore changed my existing trac ticket 85 accordingly
> https://cf-pcmdi.llnl.gov/trac/ticket/85
> to record this consensus. Note that this means we have to amend section 9.6
> as well, which explicitly disallowed missing data in aux coord vars (except
> for nonexistent elements). We have to change this, or else it would not be
> legal for Nan to store her profiles with missing pressure in discrete sampling
> geometries following sect 9, for instance.
>
> I hope I've got this right. Ticket 85 is a defect ticket, intended to correct
> mistakes uncontroversially! Therefore if anyone isn't happy with this, they
> should object on the ticket, and we'll need to open a different one to discuss
> another way to modify the convention.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120402/6b058c4b/attachment-0001.html>
Received on Mon Apr 02 2012 - 16:05:50 BST
