I noticed what appears to be a bug when projecting from UTM to Geographic
coordinates (also tried projection to and from geographic yielding the same
behavior).
In ConcatenatedTransformDirect.transform(), there is a second transform that
unnecessarily (?) swaps the x and y coordinates...
public void transform(final double[] srcPts, final int srcOff,
final double[] dstPts, final int dstOff, final int
numPts)
throws TransformException
{
assert isValid();
transform1.transform(srcPts, srcOff, dstPts, dstOff, numPts);
transform2.transform(dstPts, dstOff, dstPts, dstOff, numPts);
}
So for input you might have ((-90.28394, 34.983274), (-90.28345,
34.983277)...
resulting in ((34.983274, -90.28394), (34.983277, -90.28345)...
If I comment out the second transform, everything works normally.
I obtained the input transform via CRS.findMathTransform(). Source CRS was
obtained automatically on loading a shapefile, and target CRS was obtained
using CRS.decode("EPSG:4326").
Just wanted to report these observations. Let me know if you need more
info, have suggestions, etc.
Thanks,
Pat
v2.5-RC0 (rev 30641?)
--
View this message in context:
http://n2.nabble.com/Second-transform-swaps-coordinates-on-reprojection-in-ConcatenatedTransformDirect-tp1098052p1098052.html
Sent from the geotools-devel mailing list archive at Nabble.com.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
