[MetaCRS] A Question About The Typical Method Of CRS Transformations

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Thu May 15 09:25:25 PDT 2008


Landon Blake a écrit :
> In the first approach CRS transformations are enabled by adding
> executable code to a library. In Java this would be done with an
> accepted interface and a plug-in mechanism. In essence, I would add
> support for a new CRS by adding a JAR file to a program library.

I don't think there is any need for this mechanism at the CRS level. There is a 
need for this mechanism (at least internal to a given project) at the 
OperationMethod level, but not at the CRS level.


> In this approach, I (as the third-party code) make the library (and
> subsequently the user of the library) a promise. This promise
> essentially states: "You give me the ordinate values for your coordinate
> in some well-known pivot CRS, (like WGS84) and I will perform my black
> magic. When my black magic is finished I will return to you a coordinate
> whose ordinate values are now based on my CRS."

I would not recommand using a pivot CRS. If the source and target CRS both use 
the same datum (e.g. International 1924), using WGS84 as a pivot introduces 
complexity in the third-party code (every providers must handle datum shift in 
addition of their projection), cause a performance botleneck (convert from 
International 1924 to WGS84 than back to International 1924) and accuracy issue 
because of the additional computation and the approximation involved in various 
datum shift methods.

A good CRS library must be able to convert from an arbitrary source CRS to an 
arbitrary target CRS without the need to go through a pivot CRS, except maybe in 
a few case (for example in the way to specify Bursa-Wolf parameters - but even 
there this is not a requirement). Again the OGC specification has this notion 
(see CoordinateOperationFactory).

	Martin



More information about the MetaCRS mailing list