Hi,
I think the CF-approach of being self-explanatory rather than to rely on
external tables/database has worked very well so far. If I understand
this thread correctly, the question is how to describe a CRS.
I would rather like to turn this argument around and ask: How to
describe a CRS to get an accuracy of ~1m? Below 1m, I think even the WKT
parameters are not enough since then, conversion algorithms play a role.
In a lot WKT examples, the additional information to what is available
in CF are the TOWGS84 parameters like in the example at
http://spatialreference.org/ref/epsg/7405/prettywkt/ I guess, it would
be quite easy to add those to CF.
There exist also special 'grid-shift' files, in particular for the NAD*
datums. If or how to add those in a meaningful way to CF, I don't know.
Those are the only two parameter-sets used by many open source GIS
software for datum-shifts. (grass, postgis)
Additional EPSG codes might be a nice addition for interoperability or
reference.
Best regards,
Heiko
On 2011-10-06 15:25, 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
