[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