Custom Query (124 matches)


Show under each result:

Results (67 - 69 of 124)

Ticket Resolution Summary Owner Reporter
#76 fixed More than one name in Conventions attribute davidhassell Dave.Allured


It is proposed to support the listing of more than one convention name in the Conventions global attribute. As of CF-1.6, only the CF identification by itself is allowed. The option of a list has been in Unidata's recommendations for a long time; see references. There was some community support for this in the recent mailing list discussion.


I would like to present this in two parts. This trac ticket is part 1, which proposes to adopt verbatim, the Unidata language for listing more than one convention name. The original Unidata recommendation allows the list of names to be separated by either spaces or commas.

Part 2, which I plan to file as a separate ticket, would propose more detailed parsing rules and would probably replace the syntax description of part 1. The main objectives of part 2 would be to accommodate both unambiguous machine parsing, and flexibility in allowable characters in convention names.

Why two tickets? I think that part 1 has a better chance of approval. It accomplishes the most important objective of multiple conventions in a workable way. If part 2 succeeds, it can replace part 1, sooner or later.

The mailing list discussion beginning December 2011 should be considered part of the record for this proposal.

Text of proposed changes

Two new paragraphs are to be added at the end of the current section 2.6.1, Identification of Conventions:

It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the Conventions attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks). This is the Unidata recommended syntax from NetCDF Users Guide, Appendix B.

When CF is listed with other conventions, this asserts the same full compliance with CF requirements and interpretations as if CF was the sole convention. It is the responsibility of the data-writer to ensure that all common metadata is used with consistent meaning between conventions.

In the conformance document, add a new second line under 2.6.1 Identification of Conventions:

  • The Conventions attribute may be a single text string containing a list of convention names separated by blank space or commas, one of which shall be the full CF string as described above.


Current language of section 2.6.1, Identification of Conventions (CF-1.6)

NetCDF Users Guide, Appendix B, Attribute Conventions

List of registered conventions, NetCDF website

Ticket #27, Use namespace tags to include other conventions, 2008
(Previous proposal and discussion of Conventions attribute, not yet adopted)

#77 fixed Add sinusoidal projection davidhassell etourigny

The sinusoidal projection is used in NASA's MODIS products, and is supported by PROJ.4, Snyder and OGC WKT.

The mapping would be simple as this projection uses few existing CF projection parameters.

Proposed text :



grid_mapping_name = sinusoidal

Map parameters:

  • longitude_of_projection_origin
  • false_easting
  • false_northing

Map coordinates:

The x (abscissa) and y (ordinate) rectangular coordinates are identified by the standard_name attribute value projection_x_coordinate and projection_y_coordinate respectively.


Notes on using the PROJ.4 software packages for computing the mapping may be found at Detailed formulas can be found in [Snyder] pages 243-248.

#80 fixed Add missing CF parameters to translate Coordinate Reference System properties to/from OGC Well-Known Text format davidhassell etourigny

1. Title

Add missing CF parameters to translate Coordinate Reference System properties to/from OGC Well-Known Text format.

2. Moderator

Jonathan Gregory

3. Requirement

CF-1.6 grid mapping parameters do not allow to fully represent Geographic and Projected Coordinate Reference System (CRS) definitions in Open Geospatial Consortium (OGC) Well-Known Text format.

The following WKT nodes cannot be transformed to/from CF-1.6: PROJCS, GEOGCS, DATUM, SPHEROID, TOWGS84, PRIMEM. In particular the absence of parameters that correspond to DATUM and TOWGS84 parameters can cause datum shifting errors.

Adding new parameters to the CF grid_mapping specification would allow to translate projected and geographic CRS WKT definitions to/from CF grid_mapping definitions without loss of information.

This is a simpler and easier approach than including the full OGC WKT string (as proposed in CF Metadata trac ticket #69) and detecting the potential conflicts between the CF and WKT definitions.

4. Initial Statement of Technical Proposal

The following grid mapping attributes would be added and described in Table F1

  • horizontal_datum_name
  • towgs84 (a double-precision array, with 3, 6 or 7 values)
  • prime_meridian_name
  • reference_ellipsoid_name
  • projected_coordinate_system_name
  • geographic_coordinate_system_name

The rationale for adding the various name parameters is to ensure a 100% compatibility between OGC WKT definitions and CF grid_mapping definitions and also to make the CF definitions more representative. In general, the names should be equal to the ones used in the EPSG database (see <OGP/EPSG>).

Named datums are particularly troublesome, as there is no unique naming scheme in OGC WKT (see <link2> and <CT>). The use of TOWGS84 parameters (inside a DATUM node) allow to approximate datum shifts to the WGS84 datum, but if precise datum shifts are required (using datum shift grids), then it is important that the datums are uniquely identified. It is required to follow the OGR/Cadcorp naming scheme described in the horizontal_datum_name entry for table F1 below (to ensure compatibility with Simple Features and CT specifications).

For reference the names and parameters of PRIMEM and SPHEROID entries from the EPSG database are provided in <link1> (prime_meridian.csv and ellipsoid.csv). DATUM entries, along with their transformed names and preferred TOWGS84 parameters are given in <link1> (horiz_datum.csv).

A similar proposal could be made to account for vertical CRS (VERT_CS in WKT), but this is outside the scope of this proposal.

As an example, the modified “British National Grid” example below would loose information if it were converted to and from CF-1.6:


The PROJCS, GEOGCS, DATUM and SPHEROID names are lost, but more importantly the TOWGS84 parameters also. The SPHEROID and PRIMEM parameters are recovered due to existing CF grid_mapping parameters, and the PRIMEM name is restored because Greenwich corresponds to longitude_of_prime_meridian = 0.

Changes to section 5.6

<at the end of 1st paragraph>
The translation of CF coordinate variables to/from OGC Well-Known Text (WKT) format is summarized in a few examples below and described in detail in <link1>. 
Example 5.9. Latitude and longitude on the WGS 1984 datum

<CF definition>


        SPHEROID["WGS 84",6378137,298.257223563]],
Example 5.10. British National Grid
	char crs ;
		crs:grid_mapping_name = "transverse_mercator" ;
		crs:longitude_of_central_meridian = -2. ;
		crs:false_easting = 400000. ;
		crs:false_northing = -100000. ;
		crs:latitude_of_projection_origin = 49. ;
		crs:scale_factor_at_central_meridian = 0.9996012717 ;
		crs:longitude_of_prime_meridian = 0. ;
		crs:semi_major_axis = 6377563.396 ;
		crs:inverse_flattening = 299.324964600004 ;
		crs:projected_coordinate_system_name = "OSGB 1936 / British National Grid" ;
		crs:geographic_coordinate_system_name = "OSGB 1936" ;
		crs:horizontal_datum_name = "OSGB_1936" ;
		crs:reference_ellipsoid_name = "Airy 1830" ;
		crs:prime_meridian_name = "Greenwich" ;
		crs:towgs84 = 375., -111., 431., 0., 0., 0., 0. ;


PROJCS["OSGB 1936 / British National Grid",
    GEOGCS["OSGB 1936",
            SPHEROID["Airy 1830",6377563.396,299.3249646000044],

Changes to Table F1

horizontal_datum_nameSThe name of the geodetic (horizontal) datum, which corresponds to the procedure used to measure positions on the surface of the Earth. Valid datum names and their associated parameters are given in <link1> (horiz_datum.csv, OGC_DATUM_NAME column) and are obtained by transforming the EPSG name using the following rules (used by OGR and Cadcorp): convert all non alphanumeric characters (including +) to underscores, then strip any leading, trailing or repeating underscores. This is to ensure that named datums can be correctly identified for precise datum transformations (see <link2> for more details). Corresponds to a OGC WKT DATUM node name.
towgs84NThis indicates a list of up to 7 Bursa Wolf transformation parameters., which can be used to approximate a transformation from the horizontal datum to the WGS84 datum. More precise datum transformations can be done with datum shift grids. Represented as a double-precision array, with 3, 6 or 7 values (if there are less than 7 values the remaining are considered to be zero). Corresponds to a OGC WKT TOWGS84 node.
prime_meridian_nameSThe name of the prime meridian associated with the geodetic datum. Valid names are given in <link1> (prime_meridian.csv). Corresponds to a OGC WKT PRIMEM node name.
|reference_ellipsoid_nameSThe name of the reference ellipsoid. Valid names are given in <link1> (ellipsoid.csv). Corresponds to a OGC WKT SPHEROID node name.
geographic_coordinate_system_nameSThe name of the geographic coordinate system (GCS). Corresponds to a OGC WKT GEOGCS node name.
projected_coordinate_system_nameSThe name of the projected coordinate system (PCS). Corresponds to a OGC WKT PROJCS node name.

Changes to References

5. Benefits

By implementing this proposal, we should assure that data producers and software developers can include most of the datum information and other decriptive properties of specific projections.

This proposal is much simpler and easier to manage than the proposal in trac ticket #69, which is entirely optional and has failed to reach consensus so far.

6. Status Quo

Data producers are forced to add custom WKT entries to their data files without any standard, which does not promote interoperability.

Note: See TracQuery for help on using queries.