Hello John > 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.
I agree this is a crucial factor, it is foremost in my mind. For me the question I want to see addressed and concluded comes down to how we interpret the encoding of the scalar coordinate variable. Do we: A. recognise a semantic scalar coordinate and clearly define its properties such that it is able to deliver the required functionality for the range of uses described in the conventions and in common use in the community. B. deny the presence of a semantic scalar coordinate and apply a variety of conditional cases to the scalar coordinate variable encoding to try and decide what nature of vector coordinate with which properties should be interpreted from a particular encoding. C. ?? I favour option A, I think this is deliverable with a simple and coherent definition of the scalar coordinate variable in the conventions document and the semantics of a scalar coordinate within the model. mark ________________________________________ From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of John Caron [ca...@unidata.ucar.edu] Sent: 11 June 2013 17:01 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF-1.6 DSG clarification: time series & lat/lon coordinates 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 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
