Good points Jon,
A well documented translation from WKT to CF may be all that is needed. Our web processing software that integrates OPeNDAP data with GIS data already crosswalks CF to GIS projections for use with GeoTools. We may be able to contribute this to a standard translation. A service like
http://prj2epsg.org/ for CF to EPSG would be a good goal.
Your final note regarding empirical datums is important. EPSG would be an easy way around empirical datums. My thinking was that CF would allow a WKT or PROJ.4 string as a blob of text describing the projection, but thinking about it more, this doesn't mesh with existing CF mechanisms. The ability to parametrically define a datum for GIS interoperability is a two edged sward I guess. Potential for conflict will exist as long as people want to create custom parametric CRS grid_mappings and provide them to the GIS community.
Dave
On Oct 6, 2011, at 8:46 AM, Jon Blower wrote:
> 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: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 06 October 2011 14:26
> To: cf-metadata at cgd.ucar.edu
> 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Oct 06 2011 - 08:10:51 BST
