In case I'm using the API wrong, here's my test.<br /><br /> org.osgeo.proj4j.CRSFactory crsFactory = new org.osgeo.proj4j.CRSFactory();<br /> CoordinateReferenceSystem epsg4326 = crsFactory.createFromName("EPSG:4326");<br /> CoordinateReferenceSystem epsg28992 = crsFactory.createFromName("EPSG:28992");<br /> <br /> CoordinateTransformFactory factory = new CoordinateTransformFactory(); <br /> CoordinateTransform trans = factory.createTransform(epsg4326, epsg28992);<br /> ProjCoordinate inCoord = new ProjCoordinate();<br /> inCoord.x = 5.387638889;<br /> inCoord.y = 52.156160556; <br /> ProjCoordinate outCoord = new ProjCoordinate();<br /> trans.transform(inCoord, outCoord);<br /><br />I *think* this case should ignore the datum transform, since the input value is already in WG84.<br /><br />Thanks for the help everyone.<br /><br />On , Martin Davis <mtnclimb@gmail.com> wrote:<br />> Sounds like a possible bug, alright. I'll have a look at this test case as soon as I can.<br />> <br />> On Wed, Jan 11, 2012 at 5:51 AM, jeff fitzgerald jeffery.fitzgerald@gmail.com> wrote:<br />> <br />> I believe the problem is due to the fact that in the constructor for BasicCoordinateTransform, doDatumTransform gets set to true when I'm using EPSG:4326 and EPSG:28992. Since I'm already starting with unprojected coordinates, am I correct in thinking that that operation is not necessary?<br />> <br />> <br />> <br />> When I set the flag in the debugger to false, and BasicCoordinateTransform.datumTransform is not run, I get values I would expect (x = 155000.0000076025 y = 463000.00004944694).<br />> <br />> Fitz<br />> <br />> <br />> <br />> <br />> <br />> <br />> <br />> <br />>