Introduction

(include an explanation about previous conventions.... SPECS, CF, ACDD)

Encoding Guide

Global attributes

The following properties are intended to provide information about where the data came from and what has been done to it. This information is mainly for the benefit of human readers and data discovery mechanisms. The attribute values are all character strings. When an attribute appears both globally and as a variable attribute, the variable’s version has precedence.

Spatial Coordinates

Time Coordinates

NOTE: Definitions for "leadtime" and "time" have been taken from SPECS. The introduction of "reftime" as a variable has been adapted from SPECS global attribute description for the forecast reference time.

NOTE: Even though there are different requested time steps among the variables (6h, 12h, 24h), just one set of time axes has been defined, as that would be enough when applying the requirement of "one variable per file"

Cell boundaries

 As described in section 7.1 Cell Boundaries of CF convention.

Grid mapping

 As described in section 5.6 Grid Mappings and Projections of CF convention.

char latitude_longitude ;
    latitude_longitude:grid_mapping_name = "latitude_longitude" ;

Variables

NOTE: coordinates should list first of all the auxiliary coordinate(s) and then all the other coordinates.... SHOULD reftime and leadtime be included as well????

Static Fields

Surface Fields (defined at a given height level)

Surface Fields (not defined at a  height level)

Soil Level Fields

Accumulation Fields

Pressure Level Fields

Additional Questions to be addressed

Discussion about time coordinates

NOTE: The SPECS approach (2 1D time coordinates) has been chosen for the "providers" convention

The encoding of multiple time coordinates requires particular consideration. An explicit example of the structure is given below.

Example of encoding data with multiple time axis informations


  
double forecast_reference_time(forecast_reference_time) ;
       forecast_reference_time:bounds = "forecast_reference_time_bnds" ;
       forecast_reference_time:units = "hours since 1970-01-01 00:00:00" ;
       forecast_reference_time:standard_name = "forecast_reference_time" ;
       forecast_reference_time:calendar = "gregorian" ;

double leadtime(leadtime) ;
       leadtime:bounds = "leadtime_bnds" ;
       leadtime:units = "hours" ; 
       leadtime:standard_name = "forecast_period" ;
       leadtime:calendar = "gregorian" ;

double time(forecast_reference_time,leadtime) ;
       time:axis = "T" ;
       time:bounds = "time_bnds" ;
       time:units = "hours since 1970-01-01 00:00:00" ; 
       time:standard_name = "time" ;

float temp(forecast_reference_time,leadtime,pressure,latitude,longitude);
      temp:units = "K";
      temp:standard_name = "air_temperature";
      temp:coordinates = "time";

  

Francisco Doblas-Reyes I interpret this as the time coordinates being a hypercube, where there could be missing data; this won't be consistent with the CMIP files; I still find this confusing unless a discussion about what to do with the missing data is undertaken.


Eduardo Penabad: Wouldn't that be solved by clarifying that different variables within the same file could potentially have different time coordinates/dimensions?

Francisco Doblas-Reyes Not sure. If to simplify you assume one variable only and this variable has in one file data for two start dates, one with three forecast time steps and another one with only two, the time dimensions will be forecast_reference_time=2, leadtime=3, but one of the values of temp() will have missing values, unless I haven't understood the model.

Antonio S. Cofino Gonzalez: discussion on multi-time dimension data