Introduction
(include an explanation about previous conventions.... SPECS, CF, ACDD)
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.
...
| Attribute Name | Value | Examples | Comment |
|---|---|---|---|
| Conventions | CF convention string [Other convention] :... | "CF-1.6" "CF-1.6 C3S-0.1" | Multiple conventions may be included (separated by blank spaces) |
| title | A controlled vocabulary will be provided CF: Free text ACDD (highly recommended) | "IPSL-CM5A-LR model output prepared for CMIP5 RCP4.5" | A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names |
| references | URIs (such as a URL or DOI) for papers or other references. A valid doi is recommended CF: Free text | "doi:10.5194/gmd-8-1509-2015" | Published or web-based references that describe the data or methods used to produce it. |
| source | A methodology to build this attribute will be provided |
| The method of production of the original data. If it was model-generated, source should name the model and its version, as specifically as it could be useful |
| institution | A controlled vocabulary will be provided CF: Free text
| "Met Office" | Specifies where the original data was produced. The name of the institution principally responsible for originating this data. |
| contact | Copernicus User Support URI should be used CF: Free text | "http://copernicus-support.ecmwf.int" |
|
| project | "C3S Seasonal Forecast" should be used CF: Free text
| "C3S Seasonal Forecast" |
|
| creation_date | SPECS: YYYY-MM-DDThh:mm:ss<zone> ISO 8601:2004 extended format | "2011-06-24T02:53:46Z" | The date on which this version of the data was created. ( Modification of values implies a new version, hence this would be assigned the date of the most recent values modification. ) Metadata changes are not considered when assigning the creation_date NOTE: The ACDD 1.3 names this attribute as |
| comment | Free text |
| Miscellaneous information about the data, not captured elsewhere. |
| forecast_type | "forecast" or "hindcast" | "forecast" | To identify the type of data |
| history | Each line should begin with a timestamp indicating the date and time of day when the program was executed CF: Free Text |
| To record relevant information, such as the command history which led to this file being produced. Provides an audit trail for modifications to the original data.
|
commit, iso_lineage or lineage | Free text (ISO Lineage model 19115-2) | "Produced using CDS Toolbox v1.0" | trace of the tools/scripts used. Paco: include information about the versioning of the software used to create the data Antonio S. Cofino Gonzalez: We need a more implementtios examples on this. This could achiived in EQC WP where metadata is been part of their activities (i.e. WP4@QA4SEAS). ISO 19115-2 defines a linage model where this is been considered. TBD. |
| summary | The content will be provided ACDD (highly recommended): Text, defined phrase | A short paragraph describing the dataset | |
| keywords | The content will be provided ACDD (highly recommended) : text, controlled vocabulary | A comma separated list of key words and phrases. | |
| forecast_reference_time | SPECS: YYYY-MM-DDThh:mm:ssZ NOTE: This is ISO 8601:2004 extended format, but time zone is required to be UTC | "2011-06-01T00:00:00Z" | time of the analysis from which the forecast was made UTC zone is required |
Spatial Coordinates
| Type (CMIP5) | Coordinate Name (CMIP5) | Dimension Names (CMIP5) | Axis | standard_name | long_name (CMIP5) | units (CF canonical units) | positive | valid_min (CMIP5) | valid_max (CMIP5) | Notes | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| double | lat | lat | Y | latitude | latitude | degrees_north | N/A | -90. | 90. | Bounds required prescribed: [-90. , -89. , ..., 0., ... 90.] | |||
| double | lon | lon | X | longitude | longitude | degrees_east | N/A | 0. | 360. | Bounds required Values (1x1deg grid) requiredprescribed: dimension lon=360 [0. , 1. , ..., 358., 359.] | |||
| double | plev | plev | double | plev | plev | Z | air_pressure | pressure | Pa | down | N/A | N/A | This is also referred to as isobaric level by some tools Values prescribed: [925., 850., 700., 500., 400., 300., 200., 100., 50., 30., 10.] (NOTE: in hPa) |
| double | depth | depth | Z | depth | depth | m | down | N/A | N/A | Used Only used for soil model levels NOTE: Number and depth of levels is not prescribed by C3S | |||
| double | height | height | Z | height | height | m | up or down | CMIP5: 2mtemp: 1. | CMIP5: 2mtemp: 10. | can be used Used for single level fields (height, soil,SST) e.g. 2 m (for Temperature) | |||
C3S: string |
| realization | C3S: realization_dim CF: a different name is needed for dim/variable | N/A | E | realization | realization | 1 | N/A | N/A | N/A | members are not a physical quantity. Realization is | Discrete Axisa discrete coordinate and the mebers it categorical values (ordered or non-ordered ones) |
NOTE:
A dimension named "bounds" is also required for 'extensive' quantities.
Time Coordinates
| Finalised | Coordinate Name | Dimension Names | Axis | standard_name | long_name (SPECS) | calendar | units | positive | Notes | Y|
|---|---|---|---|---|---|---|---|---|---|---|
| leadtime | time | N/A | forecast_period | "Time elapsed since the start of the forecast" | N/A | SPECS: days | N/A |
| The interval of time between the forecast reference time and the valid time | |
| Y | time | time | T | time | "Verification time of the forecast" | gregorianstandard | SPECS: "days since 1850-01-01" C3S: requested units can be relaxed to equivalent time units | N/A | Time for which the forecast is valid |
NOTE: about forecast_reference_time as a global attribute (not generic, but SPECS use, as it will have one variable/start time per file)
Coordinate Bounds
| Finalised | Bounds Name | Dimensions | Values | Notes |
|---|---|---|---|---|
| N | time_bounds | time,bounds | dimension bounds = 2 Maybe have "bounds" in a separate table/comment, explaining that they have the same units as the variable "bounded" by them. In addition to that I would find clearer if the time variable value is always at the end of the correspondent time_bounds as this works well both for instantaneous and accumulated/aggregated variables (e.g. time=20160922 06, timebounds = [20160922 00, 20160922 06]) for 24h freqs. 2 values with the same units as "time" coordinate intervals must represent 24 hours starting at 0Z | |
| N | lat_bounds | lat, bounds | dimension bounds = 2 for grid | |
| N | lon_bounds | lon, bounds | dimension bounds = 2 for grid |
...