[Proj4j] ESPG:28992

[jeffery.fitzgerald at gmail.com]

In case I'm using the API wrong, here's my test.

org.osgeo.proj4j.CRSFactory crsFactory = new org.osgeo.proj4j.CRSFactory();
CoordinateReferenceSystem epsg4326 = crsFactory.createFromName("EPSG:4326");
CoordinateReferenceSystem epsg28992 =  
crsFactory.createFromName("EPSG:28992");

CoordinateTransformFactory factory = new CoordinateTransformFactory();
CoordinateTransform trans = factory.createTransform(epsg4326, epsg28992);
ProjCoordinate inCoord = new ProjCoordinate();
inCoord.x = 5.387638889;
inCoord.y = 52.156160556;
ProjCoordinate outCoord = new ProjCoordinate();
trans.transform(inCoord, outCoord);

I *think* this case should ignore the datum transform, since the input  
value is already in WG84.

Thanks for the help everyone.

On , Martin Davis <mtnclimb at gmail.com> wrote:
> Sounds like a possible bug, alright. I'll have a look at this test case  
> as soon as I can.

> On Wed, Jan 11, 2012 at 5:51 AM, jeff fitzgerald  
> jeffery.fitzgerald at gmail.com> wrote:

> 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?



> 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).

> Fitz









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/proj4j/attachments/20120111/266c8e29/attachment.html