ACDD 1-3 Follow-on Discussions

From Earth Science Information Partners (ESIP)

This page has been created to capture suggestions and concerns about the released ACDD 1-3 specification.

As noted in Attribute Convention for Data Discovery Future Directions, given the anticipated transition to an object-oriented version 2, significant changes to 1.3 may well be deferred in favor of the version 2 work.

Therefore, while this document has been created to collect comments and changes for 1.3, its name and introduction reflect the likely development path.

Suggestions and Concerns

It is suggested that each topic follow the following template. You might want to append '(minor fix)' to the topic name if you think this is worth an update to 1.3, as opposed to consideration in version 2.

Template Topic

Text description of the issues or suggested changes.

Graybeal (talk) 13:01, 5 January 2015 (MST) (your signature & date, inserted via 4 ~ characters)


(Comments from others go here.)

Inclusion of featureType (minor fix)

The section on 'Alignment with NetCDF and CF Conventions' infers that adherence to the CF-1.6 global attributes standard means that the mentioned featureType attribute should be included in ACDD-1.3. However, whilst all the other mentioned attributes are listed, featureType is missing from the attribute table. Should this be added for completeness?

matdon (talk) 10:40, 3 May 2017 (MDT)

More options for publisher_type entries

ACDD-1.3 Chapter 3, Global attributes, defines publisher_type as follows: "Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person."

We would request including "repository" as additional allowed entry. Alternatively, "archive“ would also be an option. The reason is that neither 'person' nor 'group', 'institution', or 'position' are adequate specifiers for data published via a repository (e.g. data published through the World Data Center for Climate (WDCC,

user74, 20:34, 25 January 2022

Recording changes in nominal position (new deployments)

CF Conventions, in the "Appendix H: Annotated Examples of Discrete Geometries", specifically in "H.2.3. Single time series, including deviations from a nominal fixed spatial location", in its example ""H.5. A single timeseries with time-varying deviations from a nominal point spatial location"", recommends the use of coordinate variables LATITUDE and LONGITUDE (with "axis" attribute) as dimensionless/scalar to report the nominal position, and, in case of the station having a GPS sensor, use the auxiliary coordinate variables PRECISE_LATITUDE and PRECISE_LONGITUDE in terms of dimension TIME to report the precise position.

Unfortunately, at the moment there's no mechanism to register nominal position changes. This changes in nominal position happens very occassionally along time due to maintenances or repositioning after drifts and do not affect the continuity of the time series in the long term.

OceanSITES includes a "platform_deployment_date" attribute, considering a deployment as an instrumented platform performing observations for a period of time, considering changes to the instrumentation or to the spatial characteristics of the platform or its instruments constitute the end of the deployment. That's not the case.

The proposal consists of adding a new recommended global attribute "deployment_positions". The attribute will be multi-valued, a comma-separated list. Each value will be a date, latitude and longitude (blank-separated). The date format will follow the Attribute Content Guidance, that is YYYY-MM-DDThh:mm:ss



:deployment_positions = "2013-06-22T12:30:00Z 44.1432 -7.7122,2017-11-23T10:00:00Z 44.1421 -7.7118";

fmanzano (talk) 13:35, 27 Jan 2023 (FMRN)