This message came from the CF Trac system. Do not reply. Instead, enter your
comments in the CF Trac system at http://kitt.llnl.gov/trac/.
#107: CF Data Model 1.7
-----------------------------+------------------------------
Reporter: markh | Owner: cf-conventions@…
Type: task | Status: new
Priority: medium | Milestone:
Component: cf-conventions | Version:
Resolution: | Keywords:
-----------------------------+------------------------------
\
\
\
\
\
\
Comment (by biard):
Replying to [comment:54 markh]:
> I have considered a [wiki:Ticket107Text9Nov13CellMethods proposed text
for cell methods]. I think the intent is correct in this text but I think
it is a little too difficult to read.
>
> With this in mind, I have prepared a
[wiki:markhDataModelDraft#CellMethod draft for the cell methods text]
which I think conveys the same intent with a little more clarity.
>
> I am still not sure that the opening sentence:
>
> ''The cell methods construct describes the methods by which the data
values of the field construct represent variation within their cells.''
>
> ...
>
> mark
>
Mark,
First a question, then some comments. Is the last line in your draft
supposed to say "The cell methods construct" instead of "The cell measures
construct"?
Now for the comments. As I look at it, the cell methods construct isn't
so much a description of how the field construct represents variation as
it is a description of how the values of the field construct were obtained
from a source data field that may or may not be present within the data
space. That is, the field construct under consideration may have been
produced from another field construct found within the file, or file set,
or cloud of field constructs (however you want to think of it) using the
methods described within the cell methods construct, or it may have been
produced from a field that was not preserved within whatever boundary
exists for your problem space. I haven't said that succinctly, but I
think that recognition of the derived nature of the field construct values
is important. There's a further wrinkle in this that isn't being captured
by the draft text, which is the ability to use the comment syntax to
describe "fuzzy" domains for the action of the cell methods. I just went
through a learning exercise about this in relation to a data set that has
data values which are mins, means, and maxs over the domain of a weather
system. There are no cells (in the regular grid way of thinking about
them), and the '( ... comment: ...)' syntax is used to capture the
specifics of the domain for the cell method.
So, what about a statement along the lines of:
{{{
The cell methods construct describes the methods by which the data values
of the field construct are derived from a source measurement field (which
may or may not be represented by an existing field construct).
}}}
This covers both the case where one field construct holds (for example)
the standard deviations of the values in another field construct and the
case where the field construct holds values derived from values outside
the scope of the data set.
Grace and peace,
Jim
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:61>
CF Metadata <http://kitt.llnl.gov/>
CF Metadata
This message came from the CF Trac system. To unsubscribe, without
unsubscribing to the regular cf-metadata list, send a message to
"[email protected]" with "unsubscribe cf-metadata" in the body of your
message.
