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
Received on Thu Oct 06 2011 - 09:44:33 BST
