Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
_If the CRS cannot be represented using the grid mapping parameters, using only the crs_wkt attribute is considered valid._ Sorry, but to my untrained eyes this essentially means software that purports to be CF compliant will have to be able to deal with WKT. It is very simple, I have a transformation that can't be represented by present grid mapping parameters, I use the crs_wkt attribute, based on the standard that says the file is CF-compliant but a lot of software that has been the basis for CF-compliance will not be able to properly read that file. I must be missing something here because I don't see anyway around this. It will create CF-complaint files that present software will not be able to properly read. Which will mean either a lot of incompatible files or possibly a lot of work for the authors of the present software that are the backbone of CF-compliance. I am also concerned that not enough feedback has been coming from the authors of these software. Most telling was the inability of the people who have driven this to name such software (so that they are not aware of the possible implications of these changes), and even more that this is being driven to benefit GDAL so that GDAL doesn't have to change (read the original posts). I want to reiterate that it is not that I don't think going in this direction in the long-run is a good idea (that is a separate issue), I just don't think the implications have been entirely thought through, in particularly the ramifications for software developers who may not have the time and resources to deal with the changes.Which is why I keep saying we should go slow on this , perhaps create a lot of sample files, create ones that use CRS that presently can't be properly represented, and see what kind of havoc it does or does not create. Only after testing over as many programs as possible, then see how this should be worded. -- 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-572780372 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
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 cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
> Are there any applications that actively read in and use the CF grid mapping > parameters? Not sure if I'm answering the right question here, but [Iris](https://github.com/SciTools/iris) ***definitely does*** explicitly interpret CF grid-mapping terms : we have explicit code for translating various types of grid-mapping to an [Iris 'coordinate_system'](). Currently supporting types : ``` albers_conical_equal_area azimuthal_equidistant lambert_azimuthal_equal_area lambert_conformal_conic lambert_cylindrical_equal_area latitude_longitude mercator orthographic polar_stereographic rotated_latitude_longitude stereographic transverse_mercator vertical_perspective ``` Most of these can also be produced as output. For instance, we are currently working on making let Iris accept a geostationary grid with missing false_easting/false_northing parameters : https://github.com/SciTools/iris/pull/3628 We currently don't support the WKT text, but could presumably consider this in future. -- 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-572643254 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
I would suggest maybe going a little slow on this one, because my guess is many people are not following this discussion, so they will not be able to respond. I have no idea what for example Panoply does, the Coastwatch tools, Thredds, Seadas, and some others I can think of, and we should be very careful we don't needlessly break things. That is why I objected to the original proposal where the WKT string would take precedence. That would almost require that WKT strings be supported in software. -- 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-572637349 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
GDAL is one more than I was aware of. I'm not aware of any others. -- 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-572632771 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
@snowman2 Are there any applications that actively read in and use the CF grid mapping parameters? -- 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-572623255 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
One minor addition: *"If the CRS cannot be represented using the grid mapping parameters, using only the CRS WKT is allowed. However, some applications will not be able to read in the CRS WKT form."* -- 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-572588900 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
