Dear Heiko,
I'm afraid I don't think the datum shift is something we can self-describe
in ~ 1 m precision by a handy set of numeric parameters. It's more messsy
thing that must be first named, not described.
Not knowing much about Norway (sorry), please find the datum shift (relative
to that of Tokyo) between Tokyo datum and WGS84 is illustrated in
URL:http://www.gsi.go.jp/common/000012836.gif for example. It's not simple
mathematical translation or rotation. Random bias is found in some regions,
due to distortion of triangulation network in pre-satellite/computer era and
sometimes actual crustal movemnents. Datum shift is actually correction of
such distortions.
So it is essential to name it, such as NAD27, Tokyo, or OSGB1936. When it
is identified by name (or better by EPSG code), user can choose db-based
conversion or approximation by TOWGS84. If we have only seven numeric
parameters, it is hard to guess original name, and that is often
insufficient for even ~ 10 m precision.
Examples for those who prefer code to lengthy text:
// 1. identification (essential)
// (1) best (concise, extendable, enough computer-readable)
grid:datum = "EPSG:4277";
// (2) better (what if other registry gets popular?)
grid:datum_epsg_code = 4277;
// (3) hmm (some people love that, but I don't know the use of lengthy
prefix)
grid:datum = "urn:ogc:def:datum:EPSG::4277"
// (4) worse: having concern of space-or-hyphen & upper-and-lowercase
problems
grid:datum = "Tokyo Datum";
// (5) worst
grid:datum = "DATUM[\"OSGB_1936\", SPHEROID[\"Airy
1830\",6377563.396,299.3249646,AUTHORITY[\"EPSG\",\"7001\"]],TOWGS84[375,-111,431,0,0,0,0],
AUTHORITY[\"EPSG\",\"6277\"]]";
// 2. approximate self-description (optional)
grid:to_wgs84 = 375.,-111.,431.,0.,0.,0.,0.;
Regards,
Eizi
----- Original Message -----
From: "Heiko Klein" <[email protected]>
To: "Jonathan Gregory" <[email protected]>
Cc: <[email protected]>
Sent: Friday, October 07, 2011 12:44 AM
Subject: Re: [CF-metadata] Question on WKT representation of CRS
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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
