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/.

#107: CF Data Model 1.7
-----------------------------+----------------------------------------------
  Reporter:  markh           |       Owner:  [email protected]
      Type:  task            |      Status:  new                          
  Priority:  medium          |   Milestone:                               
 Component:  cf-conventions  |     Version:                               
Resolution:                  |    Keywords:                               
-----------------------------+----------------------------------------------
Comment (by davidhassell):

 Replying to [comment:11 markh]:

 Dear mark

 > >   * As regards the purpose, I mentioned "shape" because it is possible
 or likely that cell measures might be defined for the geometrical form of
 the grid, such as angles between gridlines. That hasn't been done yet,
 although it's been discussed. We could foresee the possibility by
 including "shape" now, or we could modify the data model later.
 >
 > I think we should leave this alone for now

 I don't think we can. The conventions (7.2) explicitly say that cell
 measures are for "size, shape or location of the cells" and that what is
 recognised is a matter for a controlled vocabulary This should be
 reflected in the data model.


 > My point is not about whether it is prohibited in cases where inference
 may be made.  Instead I thought to indicate that where a cell measure is
 supplied, it should be used in preference to any inferred or calculated
 quantity.  I have strengthened this statement, to be clear.

 >   ''Where provided, the measure should be used in preference to
 calculating such a measure from other information.''
 >
 > I think this is the message we want to provide to data interpreters.

 No rules of precedence are stated in the conventions, so I don't think
 that we should create some for the data model.

 > > If we say "numeric", "typed" is implied, isn't it.
 >
 > I don't think it is, there are multiple types of numeric, such as int,
 float (and more in some implementations).  The array must have a specified
 type and not have it vary across its elements, I believe.

 This is a bit too implementation-specific for me. Why can't an array be
 conceptually a mixture of floats and integers?

 All the best,

 David

-- 
Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/107#comment:12>
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