[MetaCRS] Motion Vote: CS-Map RFC 2 - Redesign Datum Transformation Engine

[Hugues Wisniewski]

Hello Frank,

This design change will not remove the fact that WGS84 is the pivot datum, it will stop forcing the engine to use it as the only possible pivot, meaning that a transformation could then go from any datum to any datum directly.

The existing CsMap transformations that use parameters, use these parameters to convert to and from WGS84. These won't change.
But in case a transformation technique uses grid files, grid files usually don't go to and from WGS84

For instance NAD27 <-> NAD83, when we use those grid files, with the current design we are forced to then find another transformation to go to WGS84
ED50 <-> ERTF89 is another example

CH1903 <-> CH1903+ is currently the most extreme case inside CsMap because once this grid file is used, we need to find a way to get to WGS84 and the way to get there is to concatenate 4 tranformations: CH1903 -> CH1903+ -> CHTRS95 -> ERTF89 -> WGS84
Me might have been be ok with CH1903+ from the start in case such datum was used in the target system. So why be forced to use that long geodetic transformation path to go to WGS84? Stopping at 1903+ would be in such case, more logical, faster to execute, avoid possible loss of precision

That's why this design change is proposed
Hope that helps

Hugues

 

-----Original Message-----
From: metacrs-bounces at lists.osgeo.org [mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Martin Desruisseaux
Sent: Wednesday, July 07, 2010 8:24 AM
To: metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] Motion Vote: CS-Map RFC 2 - Redesign Datum Transformation Engine

Hello Frank

Le 07/07/10 14:50, Frank Warmerdam a écrit :
> I would appreciate hearing a bit more about the downsides of using 
> WGS84 as a pivot datum since PROJ.4 is still based on this assumption. 
> I understand that it tends to lead to kludges for some situations and 
> makes chaining challenging, but these seem to be implementation issues 
> more than fundamentals of using WGS84 as a pivot datum.

A quick search in the EPSG 7.5 database gave me 272 on a total of 1013 Coordinate Operations (considering only methods 1031-1035, 1037-1039, 9603-9607 and 9636) which don't use the WGS 84 datum (6326) neither as a source or target datum. This is 27% of the datum shifts listed in the EPSG database (using the above-cited criterion). For those who may want to know, I attached to this email the list of source and target datum that are not WGS 84 (the list is shorter than 273 entries because I omitted the operation methods variants having the same source and target datum).

If you apply the datum shifts using WGS 84 as a pivot (assuming that accurate Bursa-Wolf parameters exist for the "to WGS84" operation and the "from WGS84" 
operation - which is not garanteed), you may not get the same result for the following mathematical raison:

When using the Geocentric transformation method, performing the datum shift as two separated steps is equivalent to express the two Bursa-Wolf parameters as two affine transform matrix, multiply those matrix together, and use it for the Geocentric transformation. The matrix is derived from the Bursa-Wolf parameters as below:

http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/datum/BursaWolfParameters.html#getAffineTransform%28%29

Every Bursa-Wolf parameters can be expressed an an affine transform, but the converse is not true: an affine transform can be retrofitted in a Bursa-Wolf parameters only if the matrix is antisymetric. From my Geotoolkit experience, the result of the above-cited multiplication usually don't match this criterion.

In other words, the result of two consecutive Datum Shift is usually not expressible in a single set of Bursa-Wolf parameters, except if the datum shifts are only geocentric translations (no scale or rotation).

The above doesn't said that one method is more accurate than the other. It just said that the result are going to be different, except in the special cases where the result of the above-cited matrix multiplication is antisymetric. If a library wants to provide coordinate transformations matching the authority definition (without judgment about the accuracy of that definition), it is better to avoid going through a pivot.

The Geotoolkit.org and GeoTools libraries don't use any pivot: they apply the Bursa-Wolf parameters directly from the source to the target datum defined by EPSG, or apply the above-cited matrix multiplication when no direct path is found.

	Best regards,

		Martin