Dear Eizi,
thanks for pointing out the difference between the TOWGS84 parameters
and the proper Datum description. From a European point of view, that
seems to work much better than in Japan, but I guess this has more
historical than technical reasons.
Nonetheless, the TOWGS84 approximation are an improvement over the
existing ellipsoid information, and they are easily applicable by a
single function to most datums. Unfortunately, the EPSG database
sometimes omits the TOWGS84 approximation.
So, I still think, CF should adapt the TOWGS84 parameters to enable
direct calculations (use metadata), and allow the EPSG datum as
additional (external) metadata resource.
Best regards,
Heiko
On 2011-10-07 10:50, TOYODA Eizi wrote:
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
