This message came from the CF Trac system.  Do not reply.  Instead, enter your 
comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.

#104: Clarify the interpretation of scalar coordinate variables
-----------------------------+----------------------------------------------
  Reporter:  jonathan        |       Owner:  [email protected]
      Type:  defect          |      Status:  new                          
  Priority:  medium          |   Milestone:                               
 Component:  cf-conventions  |     Version:                               
Resolution:                  |    Keywords:                               
-----------------------------+----------------------------------------------
Comment (by markh):

 I will try to illustrate a useful example.  Consider a CF compliant NetCDF
 data variable with a 2 dimensional data array and two coordinate
 variables:

  * latitude
  * longitude

 This data variable declares auxiliary coordinates, using the coordinates
 attribute.  All but one of these are scalar coordinate variables:

  * surface_pressure(latitude, longitude)
  * a
  * p0
  * b
  * time
  * forecast_period
  * forecast_reference_time
  * source
  * experiment_id
  * model_id

 We have many such data sets.  Often these are converted from other formats
 using one of a number on converters developed inside my office and by
 collaborating organisations over the past few years.  Sometimes they are
 the results of analyses which have been persisted by researchers.

 These have always been viewed as reasonable data sets, given the
 comprehension of scalar coordinate variables.

 Under this proposal, this data set would be viewed as exactly equivalent
 to

 a CF compliant NetCDF data variable with an 11 dimensional data array and
 11 coordinate variables:

  * latitude
  * longitude
  * a
  * p0
  * b
  * time
  * forecast_period
  * forecast_reference_time
  * source
  * experiment_id
  * model_id

 along with one auxiliary coordinate:

  * surface_pressure(latitude, longitude)

 The proposal makes explicit that there should be no semantic
 differentiation between the two data sets, the first is merely an encoding
 short hand for the second.

 This interpretation does not adequately reflect the data and metadata.  It
 defines a set of independent coordinates which were not intended to be
 independent by the data creator.  This will cause considerable confusion
 in the interpretation of these data sets, most of which are in storage, to
 be returned to at a later date as required.

 If the data creators had been shown an 11 dimensional data set when they
 created it, they would have very likely raised questions about the output,
 but the scalar coordinate variable has not been interpreted in this way.
 The first encoding appeared to people to be a logical and sensible
 representation of their data.

 Scalar coordinate variables have been viewed by users as semantic
 containers: no clear statement existed in the conventions to disagree with
 this perspective.

 In most cases these data creators used software which had been deemed
 appropriate by the organisation and trusted its output would be valid.
 For years it has been deemed to be valid.

 With cases such as this in mind, I do not think the community have the
 luxury of making decisions solely based on confidence in what the authors
 of the convention had in mind when scalar coordinate variables were
 invented. I think the interpretation of these features of the convention
 by users needs to be taken into account.

 I have previously posted examples from the discrete sampling geometries
 section of the conventions which require different interpretation.  I do
 not agree with the proposed approach of handling these as further special
 cases, requiring further clarification text not in this proposal.

-- 
Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/104#comment:13>
CF Metadata <http://cf-pcmdi.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.

Reply via email to