[CF-metadata] Question on WKT representation of CRS

From: Bentley, Philip <philip.bentley>
Date: Thu, 6 Oct 2011 15:42:04 +0100

Jim et al,

Your reasoning here accords closely with the spirit of the proposal
myself and my colleagues have been working on recently to incorporate
simple CRS WKT type capabilities into the CF conventions.

We believe that the proposal addresses several of the issues raised in
recent postings to this mailing list. However, it can never be a 100%
answer to everyone's requirements and personal preferences. It won't
solve all needs across all CRS problem domains, but we think it will
move us a step in the right direction.

We are hoping to be in a position to post the proposal as a new CF trac
ticket at the beginning of next week. Hopefully the folks who have
recently posted their ideas and observations to this mailing list will
engage in the discussions against that ticket, thus improving the
proposal (and there's certainly no suggestion here that the current
email discussions should stop - plenty of good ideas being bounced
around!).

Regards
Phil

> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jim Biard
> Sent: 06 October 2011 15:15
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Question on WKT representation of CRS
>
> Hi.
>
> I worked in a previous career phase with photogrammetry and GIS.
> Precise knowledge of the coordinate system is often critical
> in these domains. I appreciate the concern about the
> "opacity" of the WKT or
> proj4 text blocks, but I don't think it is wise to develop
> what will amount to yet another standard for representing
> coordinate systems. The reason WKT blocks can get so long
> and involved is because different coordinate systems use
> different algorithms, and some of these vary widely from one another.
>
> I suggest that we leave all of that to others that are expert
> in that field. If you look at the EPSG code entries at
> spatialreference.org, you will see that nearly all of them
> have a name. Why not adopt the approach of providing the
> name in an attribute, and the WKT text in another? Give them
> names like coordinate_system_name and coordinate_system_wkt.
> If you are working in three dimensions and require accurate
> geo-positioning, you will need to specify the vertical datum
> as well. We could use attributes named vertical_datum_name
> and vertical_datum_wkt when these are needed.
>
> The goal here is to clearly define the coordinate systems in
> use, so that users can perform whatever operations they need
> to perform with the geographical coordinates contained in
> CF-compliant netCDF files. The current CF scheme (and any
> that continues in the current direction) seems to me to make
> it more difficult for a user to accomplish her work, since
> the coordinate system parameters must be read out of the file
> and converted into a standard form that coordinate system
> software packages can actually use. Adopting an
> international standard for coordinate system representation
> will make life easier for users, even if it means that an
> opaque text block is included in our netCDF files.
>
> Grace and peace,
>
> Jim Biard
>
Received on Thu Oct 06 2011 - 08:42:04 BST