Hi All,
I agree with Eizi, using EPSG code is a good idea. High accuracy
conversion from one datum to another is not always a simple mathematical
transformation. For such transformations, one has to "know" the datum
rather than describe using a small set of parameters. In the US, one
example of a tool used for conversion between datums is NADCON which can
do transformations from NAD 27 to NAD 83. As I understand, it uses an
entire database of values underneath to achieve the transformation.
Upendra
On 10/7/2011 4:50 AM, 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
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> 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 - 12:32:44 BST
