Custom Query (125 matches)


Show under each result:

Results (85 - 87 of 125)

Ticket Resolution Summary Owner Reporter
#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.

#85 fixed Link Appendix H from section 9, and clarify missing data requirements davidhassell jonathan

We removed most of the detail regarding the storage of discrete sampling geometries from the text in section 9 to Appendix H, but as far as I can see we forgot to make links to Appendix H. To correct this defect, I propose that we:

  • Add this sentence to the end of the first paragraph of section 9.1, just before the table: "Details and examples of storage of each of these feature types are provided in Appendix H, as indicated in the table."
  • Add a column to Table 9.1, headed "Links", in which the cells indicate and provide links to the relevant sections H.1-H.6.

In section 9.6, we introduced the possibility of missing data in auxiliary coordinate variables for discrete sampling geometries, and Appendix A notes that missing data is only allowed for section 9.6. To be clear, I think we should note this in section 2.5.1 "Missing data" also. I propose that we append this sentence to the first paragraph of 2.5.1.

Missing data is not allowed in coordinate variables or auxiliary coordinate variables, except for auxiliary coordinate variables in discrete sampling geometries (Section 9.6, "Missing data").

Also, I propose that in the "Links" column of Appendix A, we add links to section 2.5.1 and 9.6 for _FillValue (in addition to the link to the NUG), and to section 9.6 for missing_value (2.5.1 is already linked).


Note: See TracQuery for help on using queries.