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" <Heiko.Klein at met.no>
To: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
Cc: <cf-metadata at cgd.ucar.edu>
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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Oct 07 2011 - 02:50:53 BST
