<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
Hi Fitz,<BR>
<BR>
I just wrote a test script and can confirm your result.<BR>
Then I remembered that there was a difference between proj (c-version) and proj4j in handling the +towgs parameters.<BR>
The c version has some conversion code for parameters 4-7.<BR>
Parameters 4-6 get converted from arc seconds to radians. (param=param*pi/180/3600)<BR>
Parameter 7 gets converted from ppm to scaling factor (param=1+param/1000000)<BR>
<BR>
Here's the code from pj_datum_set.c:<BR>
/* transform from arc seconds to radians */<BR>
projdef->datum_params[3] *= SEC_TO_RAD;<BR>
projdef->datum_params[4] *= SEC_TO_RAD;<BR>
projdef->datum_params[5] *= SEC_TO_RAD;<BR>
/* transform from parts per million to scaling factor */<BR>
projdef->datum_params[6] = (projdef->datum_params[6]/1000000.0) + 1;<BR>
<BR>
This code seems to be missing in proj4j.<BR>
<BR>
Apart from that, as far as I know, the +towgs should be :+towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812<BR>
Applying the above calculation to the last 4 parameters as a work around gives:<BR>
+towgs84=565.237,50.0087,465.658,-1.972e-6,1.7004e-6,-9.0677e-6,1.0000040812<BR>
<BR>
When I put this into the nad/epsg file for proj4j I thought I would get the same results you got from proj, but I didn't.<BR>
I get 155029.79163595638 463109.9538034333 for your reference point instead.<BR>
<BR>
However, the result seems to agree with some other data I have. I'll do some more research tomorrow.<BR>
<BR>
Gertjan Idema<BR>
<BR>
<BR>
<BR>
On Wed, 2012-01-11 at 09:51 -0400, jeff fitzgerald wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
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>
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>
On Wed, Jan 11, 2012 at 9:41 AM, Gertjan Idema <<A HREF="mailto:g.idema@zonnet.nl">g.idema@zonnet.nl</A>> wrote:<BR>
<BLOCKQUOTE>
I haven't seen this, but then I haven't used proj4j for a while.<BR>
The result you give for proj4j is definitely wrong. Any valid EPSG:28992 coordinate has x<y .<BR>
<BR>
<FONT COLOR="#888888">Gertjan</FONT> <BR>
<BR>
<BR>
On Wed, 2012-01-11 at 09:09 -0400, jeff fitzgerald wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Hey Martin,<BR>
<BR>
There just seems to be a big discrepancy for me between proj and proj4j.<BR>
<BR>
Using the string with the tows84 method and 5.387638889,52.156160556 as my test point, <BR>
- Proj gives me 154976.16420640881,463086.51164757559<BR>
- proj4j gives me x = 4761867.817294979 y = 2527483.7229957823<BR>
<BR>
Does anyone else get similar results?<BR>
<BR>
Thanks.<BR>
<BR>
Fitz<BR>
<BR>
On Tue, Jan 10, 2012 at 1:13 AM, Martin Davis <<A HREF="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</A>> wrote:<BR>
<BLOCKQUOTE>
Some more information on this issue.<BR>
<BR>
The addition of the towgs84 parameter happened last August, as a result of this ticket:<BR>
<BR>
<A HREF="http://trac.osgeo.org/proj/ticket/96">http://trac.osgeo.org/proj/ticket/96</A><BR>
<BR>
The SVN version of EPSG:28992 has the +towgs parameter, whereas the version in the PROJ.4 distro archive does not. <BR>
<BR>
Apparently this change was due to user demand, for what is a apparently a more accurate definition. If you search for "EPSG:28992" you'll find lots of discussion about this. This blog post seems to be authoritative on the subject:<BR>
<BR>
<A HREF="http://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/">http://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/</A><BR>
<BR>
Out of curiousity, what are the issues that you're seeing with this new definition? <BR>
<BR>
<BR>
On Mon, Jan 9, 2012 at 8:16 AM, <<A HREF="mailto:jeffery.fitzgerald@gmail.com">jeffery.fitzgerald@gmail.com</A>> wrote:<BR>
<BR>
<BLOCKQUOTE>
Hey,<BR>
<BR>
I noticed that the epsg file that ships with proj4j has a different entry for ESPG:28992 than I have seen in proj.<BR>
<BR>
proj4j epsg<BR>
# Amersfoort / RD New<BR>
<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs <><BR>
<BR>
gdal epsg<BR>
# Amersfoort / RD New<BR>
<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs <><BR>
<BR>
Does anyone know why? It was causing me some trouble until I removed the towgs84.<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Proj4j mailing list<BR>
<A HREF="mailto:Proj4j@lists.osgeo.org">Proj4j@lists.osgeo.org</A><BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/proj4j">http://lists.osgeo.org/mailman/listinfo/proj4j</A><BR>
<BR>
</BLOCKQUOTE>
<BR>
<PRE>
_______________________________________________
Proj4j mailing list
<A HREF="mailto:Proj4j@lists.osgeo.org">Proj4j@lists.osgeo.org</A>
<A HREF="http://lists.osgeo.org/mailman/listinfo/proj4j">http://lists.osgeo.org/mailman/listinfo/proj4j</A>
</PRE>
</BLOCKQUOTE>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Proj4j mailing list<BR>
<A HREF="mailto:Proj4j@lists.osgeo.org">Proj4j@lists.osgeo.org</A><BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/proj4j">http://lists.osgeo.org/mailman/listinfo/proj4j</A><BR>
<BR>
</BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
</BODY>
</HTML>