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/.
#95: Development of CF 1.5 Data Model -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear Mark and David This debate seems to be rather confused. I am not quite sure what we are arguing about or whether there needs to be an argument! One particular point of confusion is about the time coordinates in Mark's example, I suspect. I think Mark means that ''forecast_period = time - forecast_reference_time'', so only two of these are independent. This means there are not three domain axes of time, but it's not obvious from the description of the example whether there is one or two. The lack of clarity perhaps arises because the description doesn't say what the fields look like in netCDF. I think Mark's intention could be represented in CF-netCDF like this: * `source` and `institution` are string-valued scalar coordinate variables. * `height` and `time` are size-one (Unidata) coordinate variables. * `ensemble` is a numeric scalar coordinate variable. * ''either'' `forecast_reference_time` ''or'' `forecast_period` is a size-one numeric (Unidata) coordinate variable, and the other is an auxiliary coordinate variable with the same dimension. * The data variable is dimensioned `(time,height,latitude,longitude)`. In the CF data model, this becomes a Field with * eight domain axis constructs: '''s''', '''i''', `height`, `time`, `longitude`, `latitude`, `ensemble` and ''either'' `forecast_reference_time` ''or'' `forecast_period`. * a data array dimensioned by the ordered list of domain axes `[time, height, latitude, longitude]` (or perhaps the other way round! - I'm not sure which convention we are using). It's 4D, not 2D, if the position of `time` and `height` are significant. * six numeric dimension coordinate constructs: `height`, `time`, `longitude`, `latitude`, `ensemble` and ''either'' `forecast_reference_time` ''or'' `forecast_period`, each dimensioned by the corresponding domain axis construct. * one numeric auxiliary coordinate construct: ''either'' `forecast_period` ''or'' `forecast_reference_time`, dimensioned by the same domain axis construct as whichever is the dimension coordinate construct. * two string-valued auxiliary coordinate constructs: `source(`'''s'''`)` and `institution(`'''i'''`)`. These are not dimension coordinate constructs (`source(source)` and `institute(institute)`) because CF does not permit string-valued coordinate variables. There are alternatives in the netCDF, which would imply corresponding differences in the CF data model description e.g. * `source` and `institution` could be string-valued auxiliary coordinate variables with the `ensemble` dimension, as David assumed. Then the domain axis constructs '''s''' and '''i''' would not exist, and the `ensemble` domain axis construct would dimension these auxiliary coordinate constructs. * `forecast_reference_time` and `forecast_period` could both be auxiliary coordinate variables with the `time` dimension, as David assumed. Then they would not have domain axis constructs; they would be dimensioned with the `time` axis construct. * The data variable could be dimensioned `(latitude,longitude)`. Then the field data array would be 2D in the data model. There would be no other difference. These differences would affect the aggregation, because aggregation is a process of concatenating dimensions, and therefore depends on which dimensions there are. After aggregation, the data array will have more than two dimensions of size greater than one. If the input data arrays had only `latitude` and `longitude` as dimensions, the position of the new dimensions in the order is not defined by the input, and hence would have to be decided by the aggregating software, or by instructions given to the aggregating software by the user. As has been said, the aggregation rules are not part of the CF data model. I hope that helps a bit. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:51> 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.
