<!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 TEXT="#000000" BGCOLOR="#ffffff">
Hi Martin,<BR>
<BR>
Thank for the quick fix. I works just fine.<BR>
I compared the results from the two +towgs string version to the results of Postgis.<BR>
As you already noticed, the difference are small, but the +towgs version below is much closer to the Postgis results:<BR>
+towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812<BR>
However, this ticket: <A HREF="http://trac.osgeo.org/gdal/ticket/1987">http://trac.osgeo.org/gdal/ticket/1987</A> advocates the +towgs string currently in proj4j.<BR>
That might indicate that I have the wrong +towgs string in my postgis version. <BR>
<BR>
Here are my proj4j results with the +towgs string above:<BR>
5.387638889,52.156160556 (EPSG:4326) -&gt; 155029.78919920223,463109.9541111593 (EPSG:28992)<BR>
155000.0,463000.0 (EPSG:28992) -&gt; 5.3872035804217715,52.15517230193107 (EPSG:4326)<BR>
50000.0,350000.0 (EPSG:28992) -&gt; 3.8871491439988644,51.12978774865556 (EPSG:4326)<BR>
50000.0,600000.0 (EPSG:28992) -&gt; 3.8094540580375993,53.37600149352827 (EPSG:4326)<BR>
250000.0,350000.0 (EPSG:28992) -&gt; 6.7444286180777056,51.13154120698355 (EPSG:4326)<BR>
250000.0,600000.0 (EPSG:28992) -&gt; 6.81474749295472,53.37787337579902 (EPSG:4326)<BR>
250000.0,600000.0 (EPSG:28992) -&gt; 6.814747494636736,53.377873382361884 (EPSG:4326)<BR>
<BR>
One more very strange thing I can't explain can be seen in the last two lines.<BR>
When I run the conversion twice (or more times) the results don't agree.<BR>
Even when I create new Objects for the CRSFactory, the CoordinateReferenceSystems and the BasicCoordinateTransforms.<BR>
The difference are maybe to small to worry about, but to me it's very strange.<BR>
Can you confirm this behavior?<BR>
<BR>
Gertjan Idema<BR>
<BR>
<BR>
On Wed, 2012-01-11 at 21:47 -0800, Martin Davis wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    As is usually the case with projection issues, this is getting complicated...<BR>
    <BR>
    Gertjan, in the test you give below you are using a slightly different +towgs string than the one in the PROJ4 definition.&nbsp; However, the effect of the difference seems to be fairly minor. I just tested both towgs84 definitions in Proj4J and the results are within a few mm of each other.&nbsp; (This is *with* the towgs84 parameter conversion implemented, of course!)<BR>
    <BR>
    So, it would be great if you can confirm that the value below is correct within mm (using some independent program?).&nbsp; In that case, Proj4J seems to be working correctly.&nbsp; <BR>
    <BR>
    Not sure why the PROJ4 value that Jeff reported was off by 30 or so metres, though.<BR>
    <BR>
    <BR>
    <BR>
    On 1/11/2012 3:03 PM, Gertjan Idema wrote: <BR>
    <BLOCKQUOTE TYPE=CITE>
        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>
        &nbsp; /* transform from arc seconds to radians */<BR>
        &nbsp; projdef-&gt;datum_params[3] *= SEC_TO_RAD;<BR>
        &nbsp; projdef-&gt;datum_params[4] *= SEC_TO_RAD;<BR>
        &nbsp; projdef-&gt;datum_params[5] *= SEC_TO_RAD;<BR>
        &nbsp; /* transform from parts per million to scaling factor */<BR>
        &nbsp; projdef-&gt;datum_params[6] =&nbsp; (projdef-&gt;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>
        &nbsp; +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>
    </BLOCKQUOTE>
<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>
</BODY>
</HTML>