Hello @JonathanGregory > I think your proposal makes sense, if you're sure that the variables listed > in the `grid_mapping` attribute (in the extended form) always correspond to > the coordinate variables of the OGC CRS, do they?
I think that they have to. I think that for a CRS to be used in its WKT form, then the variables listed in the `grid_mapping` attribute must correspond, otherwise the mismatch cannot be handled by downstream software. This is an onus on the data provider, they are asserting this by providing the WKT encoding for the CRS. > In your text, I think it would be good to say that the order of the variables > in the `grid_mapping` attribute is significant only if `crs_wkt` is also > specified, because it doesn't have a meaning for the CF metadata, in which > order is not defined. I agree, perhaps: `5.6. Horizontal Coordinate Reference Systems, Grid Mappings, and Projections` section: > Where an extended "grid_mapping_variable: coordinate_variable > [coordinate_variable …]" entity is defined, then the order of the coordinate > variable references within the definition provides an explicit order for > these coordinate value variables, if they are to be combined into individual > coordinate tuples. > > This order is only significant if `crs_wkt` is also specified within the > referenced grid mapping variable. Explicit 'axis order' is important when > the grid_mapping_variable contains an attribute `crs_wkt` as it is mandated > by the OGC CRS-WKT standard that coordinate tuples with correct axis order > are provided as part of the reference to a Coordinate Reference System. `5.6.1 Use of the CRS Well-known Text Format` section: > Where crs_wkt is added to a grid_mapping, the extended syntax for the > grid_mapping attribute enables the axis order for the coordinates being > referenced to be explicitly stated. The explicit definition of axis order is > expected by the OGC standards for referencing by coordinates. > > The order of the coordinate variable references within the `grid_mapping` > attribute definition defines the order of elements within a derived > coordinate value tuple. This enable an application reading the data from a > file to construct an array of coordinate value tuples, where each tuple is > ordered to match the specification of the coordinate reference system being > used. > > For example, a file has two coordinate variables, `lon` and `lat`, and a grid > mapping variable `crs` with an associated `crs_wkt` attribute; the WKT > definition defines the AXIS order as ["latitude", "longitude"]. The > `grid_mapping` attribute is thus given a value `crs:lat lon` to define that > where coordinate pairs are required, these shall be ordered (lat, lon), to be > consistent with the provided `crs_wkt` string (and not order inverted). Is this a slight improvement on the previous text? thank you mark -- 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/223#issuecomment-570225854 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].
