Yeroc a écrit : > Can anyone provide a reasonable explanation as to why the MathTransform > provided by GeoTools to convert coordinates isn't returning a DirectPosition > with the CRS set? (I'm not actually sure which concrete class is > responsible for this since it's all hidden behind factories.) Instead, when > I later get the CRS from the position I get a null return value. Is this a > bug? It certainly isn't desired behavior in my case!
MathTransforms don't know anything about the source and target CRS (except their dimension) - there is no getSourceCRS() and getTargetCRS() methods in MathTransform. This kind of information is kept into CoordinateOperation instead, together with other metadata like area of validity and transformation accuracy: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/operation/CoordinateOperation.html In many case, the same MathTransform can be used with different combinaison of source and target CRS. For example an AffineTransform[0,1,0;1,0,0] can be used for swapping longitude and latitude axis of about any CRS, not a specific one. A MercatorProjection may be a single step in transformation chain, and this step may be shared by numerous (sourceCRS, targetCRS) pairs. If source and target CRS were stored as MathTransform fields, a different MathTransform instance would be required for each (sourceCRS, targetCRS) pair. In the case of AffineTransform and MercatorProjection, the cost of creating many instances is small. However some MathTransform may be more heavyweight, for example a datum shift backed by some grid data line NADCONTransform. Generally speaking CoordinateOperation is a light wrapper containing various metadata (including source and target CRS), and MathTransform may be a heavy implementation performing the transformation work. In addition, MathTransform do not apply necessarly on coordinates. It can apply on any arrays of values. This is why it is called MathTransform, not CoordinateTransform. This choice is not mine - it was specified in OGC 01-009 (as well as the inexistence of getSourceCRS() and getTargetCRS() methods), together with the mention that math transform can be applied to something else than coordinates, like color conversions. Actually the GridCoverage module use MathTransform for pixel values conversions. However I admit that coordinate transformation is by far the primary usage for math transform. One additional issue is that setting the CRS has an (admitly small) cost. To be consistent, we should also check that the DirectPosition to convert has the expected sourceCRS, which is a more expensive check. Having MathTransform as fast as we can was a strong requirement. If you need to set the DirectPosition's CRS, would it be okay if you create a convenience method like: DirectPosition transform(CoordinateOperation op, DirectPosition pos) You can set the DirectPosition's CRS and then transform it using the information available in the CoordinateOperation. Since you are at it, you could also check that the source position is inside the CoordinateOperation area of validity. All those checks and settings have a cost; so it may be in user's hands to choose the right balance between the cost and the features he wants. Martin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
