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
On 10/6/2011 9:25 AM, Jonathan Gregory wrote:
> 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
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
Received on Thu Oct 06 2011 - 08:15:26 BST
