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
[email protected]
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
[email protected]
828-271-4900
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
