Hi All,
I agree with Roy on this. The addition of optional WKT or PROJ.4 string would be an appealing option for interoperability.
With NetCDF-CF becoming a WCS payload, GIS software will increasingly be directly ingesting data with CF metadata. ArcGIS already reads and writes netCDF but doesn't pay any attention to the CF projection information as it stands. An optional WKT field would be a perfect integration point for GIS. Like with Shapefiles, the .prj is technically optional but given a shapefile lacking a .prj, the user is forced to choose/make an assumption of what to use. A well formed WKT string includes EPSG codes as authority codes for the parameters in the string. This information would give, for example, THREDDS WCS implementation an EPSG code to advertise in the WCS describeCoverage supportedCRS field.
The existing CF CRS/projections would be a good guideline for users of the CF standard regarding what CRS handling has been implemented broadly. This potential duplication will likely be needed as long as we have implementations wanting to use NetCDF coming from the existing CF standard (NetCDF-Java) vs. existing GIS standards (ArcGIS).
In terms of WKT being opaque or not self describing, this is simply not true. While the terms and acronyms may be jargon from the geospatial community, a simple google search will allow familiarization with the terms used.
Addition of an EPSG code, in addition to existing CF grid_mapping parameters would be OK, but the parametric nature of CF grid_mappings matches WKT or PROJ.4 much better.
For what its worth,
Cheers
Dave Blodgett
On Oct 4, 2011, at 9:38 AM, Lowry, Roy K. wrote:
> Hello Jonathan,
>
> I would argue that incorporation of a convention from an established community, no matter how opaque it may appear, provides an extremely useful interoperability bridge. I would not, however, argue that such a convention should be used to replace what is already present in CF. I know this results in duplication of information, but I'm coming to realise that this is a necessary evil.
>
> Cheers, Roy.
>
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 04 October 2011 15:28
> To: Patrick Sunter
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Question on WKT representation of CRS (Bentley, Philip)
>
> Dear all
>
> Patrick's example is useful.
>
>> DATUM["Geocentric_Datum_of_Australia_1994",
>> SPHEROID["GRS 1980",6378137,298.2572221010042,
>> AUTHORITY["EPSG","7019"]],
>> TOWGS84[0,0,0,0,0,0,0],
>> AUTHORITY["EPSG","6283"]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433],
>> AUTHORITY["EPSG","4283"]],
>>
>> whereas in CF-1 we can mainly only save the spheroid info:
>> albers_conical_equal_area#semi_major_axis=6.37814e+06
>> albers_conical_equal_area#inverse_flattening=298.257
>
> The CF convention as it stands can say a lot less, but it does look more
> self-explanatory to me! The meaning of the WKT is not clear to me. I'm quite
> uneasy about importing a convention into CF which produces opaque metadata
> like this, even though it is no doubt machine-readable.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> --
> This message (and any attachments) is for the recipient only. NERC
> is subject to the Freedom of Information Act 2000 and the contents
> of this email and any reply you make may be disclosed by NERC unless
> it is exempt from release under the Act. Any material supplied to
> NERC may be stored in an electronic records management system.
> _______________________________________________
> 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 - 07:40:34 BST
