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" <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
Received on Mon Oct 10 2011 - 02:03:08 BST
