Just to be clear, this proposal does not propose to remove or override the 
`grid_mapping` parameters. It's main goal is co-existence with the CRS WKT.

Proposed WKT string statement modifications (modifications in italics):
> The crs_wkt attribute is intended to act as a supplement to other 
> single-property CF grid mapping attributes (as described in Appendix F); it 
> is not intended to replace those attributes. If data producers omit the 
> single-property grid mapping attributes in favour of the compound crs_wkt 
> attribute, software which cannot interpret crs_wkt will be unable to use the 
> grid_mapping information. Therefore the CRS should be described as thoroughly 
> as possible with the single-property attributes as well as by crs_wkt. *If 
> the CRS cannot be represented using the grid mapping parameters, using only 
> the crs_wkt attribute is considered valid. *

>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. 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. *If both a crs_wkt and grid mapping attributes 
>exist, it is assumed that they do not conflict. As such, information from 
>either one (or both) may be used to represent the CRS of the file, recognizing 
>that the grid mapping parameters should always be completed as fully as 
>possible.* ~~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#issuecomment-572767885
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].

Reply via email to