Hi Mark and Jonathan:
I will say straight up that I dont understand the implications of this
particular discussion. But in case its helpful, I have found it
important to separate the data model and the encoding of the model in
the netCDF file. Probably you are both already doing that, but I wasnt sure.
John
On 6/7/2013 3:23 AM, Hedley, Mark wrote:
Hello Jonathan
As a result of this discussion, it seems me that for a DSG (which is indicated
by the presence of featureType), scalar coordinate variables have to be
interpreted as auxiliary coordinate variables of an omitted size-one instance
dimension. That is what is implied by section 9.2. It's different from the
interpretation that is implied by section 5.7, which should exclude DSGs (and
predates DSGs).
I don't think this approach holds together safely. 9.1 describes data
variables and space-time (auxiliary) coordinate variables as varying with index
dimensions.
The different feature types have different expectations for the relationship
between dimensions, data and space-time coordinates.
9.2 describes the special case where the instance dimension is omitted and the
space-time coordinates are scalar coordinate variables.
Interpreting sampling geometry scalar coordinates as a set of special cases,
all different from the special cases of interpreting scalar coordinates in the
absence of a featureType, is placing extensive complexity in the conventions
and their interpretations. I think this is asking too much of data producers
and data consumers.
In many cases I think data producers have interpreted and will interpret the
conventions (paraphrasing extensively) as 'these are just scalars'.
We also have to be mindful of the large selection of data sets with some
sampling geometry like properties but which do not use the featureType
attribute, e.g. from CF 1.5 or earlier.
I see no problem with having different interpretations for different purposes.
I see particular problems with this statement. Treating the core types of the
CF conventions differently depending on the context, such as by featureType and
variable type introduces extensive complexity in data creation and
interpretation, which I think CF should be very careful of. I do not think this
is necessary.
Continuing and expanding the special casing for scalar coordinate variables in
various contexts will cause significant issues for data consumers.
I am confident that scalar coordinate variable interpretation can be clearly
defined in a manner consistent with the use of scalar coordinates in previous
versions of the conventions. I think that delivering a coherent definition of
simple scalar coordinates for CF 1.7 will continue to support current usage and
provide helpful clarification for future usage.
Examples 5.11, H4, H5 and H9 all use scalar coordinate variables in a way which
I feel can be neatly supported by a simple definition of the scalar coordinate
variable, distinct from vector coordinates.
Some more examples will help to clarify this for users of the conventions.
mark
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
