Hi Jonathan, all, In my view this is a reasonable approach, at least as a starting-point. I have a practical worry that it might be a lot of effort to port the WKT grammar to CF-land and that this will duplicate a lot of previous GIS work, but I do agree that the WKT and Proj.4 syntaxes are sufficiently alien and opaque that it's worth at least scoping this out. For practical GIS interoperability it would be useful to formally define a two-way WKT-CF translator that could be implemented in software libraries.
One obstacle could be that the WKT syntax is hierarchical, whereas NetCDF attributes are not, although links can be defined through custom mechanisms. I also like the idea of allowing EPSG codes. One technical nuance is that we'd need some way to map the axes of the CRS in the (externally-held) EPSG definition to the (internally-held) CF coordinate axes. There are some pitfalls: "EPSG:4326" and "CRS:84" are the same CRS with the axes reversed. I've also tripped over axis order issues in polar stereographic projection definitions (different versions of the same database define different axis orders). A final note: I think the only practical way to specify certain datums is to use an opaque code. They are sometimes empirically defined and CF probably doesn't want to have to carry all the formulae and fitting parameters. We may have to allow this as an exception to the usual CF guidelines. Hope this helps, Jon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Gregory Sent: 06 October 2011 14:26 To: [email protected] Subject: [CF-metadata] Question on WKT representation of CRS Dear all I agree with Seth and Bryan in the point made earlier by Balaji that model datasets may not truly correspond to any real-world CRS. But for observational datasets and model datasets where applicable, we should provide the optional facility to be more precise, as Bruce says. I think this is opaque: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]] because the terms it in are not spelled out sufficiently for me to know what they mean. It is human-readable, indeed, but not self-explanatory. I am very concerned that we should not import metadata wholesale without being clear about how it relates to the rest of CF metadata. Hence I would prefer an incremental addition to the existing facilities of grid_mapping, which I think is what Eizi suggests. Can we identify some specific extensions which people need to be made? The use of EPSG codes would be non-self-describing, but we could provide both EPSG code and grid_mapping. In that case it would be good to be able to verify they were consistent. That would require an online EPSG database that could be used by the CF checker, and some work by someone to establish the correspondence between EPSG terms and CF metadata. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
