**Title:** Make CRS WKT dominant over grid mapping attributes **Moderator:** ??? **Moderator Status Review [last updated: YY/MM/DD]:** ??? **Requirement Summary:** I propose instead that if the CRS WKT is present and can be read in by the software program, that should be the official CRS of the file by CF standards and all other grid mapping parameters should be ignored. However, if the software program cannot read in the CRS WKT, the grid mapping parameters should be used to represent the CRS.
**Benefits:** 1. The CRS WKT is a flexible format and can represent more CRS than what is currently supported by the `grid mapping` conventions. 2. Switching to have the CRS WKT be dominant will simplify the lives of software developers so they can just read in the WKT without a need to compare it against the individual parameters in the grid mapping. But, if it is not present, then they can just read in the grid mapping parameters to construct the CRS. 3. The PROJ strings mentioned in the [CF mapping docs](https://github.com/cf-convention/cf-conventions/wiki/Mapping-from-CF-Grid-Mapping-Attributes-to-CRS-WKT-Elements#table-3---common-projection-parameter-names) as a potential mapping are limited and usually cannot fully represent the CRS. The [PROJ FAQ](https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems) recommends users use the WKT form and is now supported in the PROJ community. 4. In the GDAL code ([link](https://github.com/OSGeo/gdal/blob/b6c2515da6ef1166b0b76d5ecca0c0943489ae2f/gdal/frmts/netcdf/netcdfdataset.cpp#L3782-L3797)) it attempts to read in both the WKT and the CF grid mapping parameters. If they both exist and the CRS created are different, the WKT version of the CRS is dropped instead of comparing the individual parameters and replacing them. I assume it was due to the difficulty of individually replacing the parameters. With this change, that logic would be simplified considerably as if the WKT version exists, the program is done. **Status Quo:** http://cfconventions.org/cf-conventions/cf-conventions.html#use-of-the-crs-well-known-text-format mentions ``` There will be occasions when a given CRS property value is duplicated in both a single-property grid mapping attribute and the crs_wkt attribute. In such cases the onus is on data producers to ensure that the property values are consistent. However, in those situations where two values of a given property are different, then the value specified by the single-property attribute shall take precedence. For example, if the semi-major axis length of the ellipsoid is defined by the grid mapping attribute semi_major_axis and also by the crs_wkt attribute (via the WKT SPHEROID[…] element) then the former, being the more specific attribute, takes precedence. Naturally if the two values are equal then no ambiguity arises. ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
