Thanks for the sample data. <div><br></div><div>My preference is to remain in synch with PROJ4, so I'll leave the towgs parameter the way it is for now. As you say, the differences are small anyway.</div><div><br></div>
<div>The changing results over repeated runs is very strange. I'll look into that.<br><br><div class="gmail_quote">On Thu, Jan 12, 2012 at 2:43 AM, Gertjan Idema <span dir="ltr"><<a href="mailto:g.idema@zonnet.nl">g.idema@zonnet.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div 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" target="_blank">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) -> 155029.78919920223,463109.9541111593 (EPSG:28992)<br>
155000.0,463000.0 (EPSG:28992) -> 5.3872035804217715,52.15517230193107 (EPSG:4326)<br>
50000.0,350000.0 (EPSG:28992) -> 3.8871491439988644,51.12978774865556 (EPSG:4326)<br>
50000.0,600000.0 (EPSG:28992) -> 3.8094540580375993,53.37600149352827 (EPSG:4326)<br>
250000.0,350000.0 (EPSG:28992) -> 6.7444286180777056,51.13154120698355 (EPSG:4326)<br>
250000.0,600000.0 (EPSG:28992) -> 6.81474749295472,53.37787337579902 (EPSG:4326)<br>
250000.0,600000.0 (EPSG:28992) -> 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<div><div></div><div class="h5"><br>
<br>
<br>
On Wed, 2012-01-11 at 21:47 -0800, Martin Davis wrote:<br>
</div></div><blockquote type="CITE"><div><div></div><div class="h5">
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. 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. (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?). In that case, Proj4J seems to be working correctly. <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>
/* 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>
</blockquote>
</div></div><pre>_______________________________________________
Proj4j mailing list
<a href="mailto:Proj4j@lists.osgeo.org" target="_blank">Proj4j@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/proj4j" target="_blank">http://lists.osgeo.org/mailman/listinfo/proj4j</a>
</pre>
</blockquote>
<br>
</div>
<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" target="_blank">http://lists.osgeo.org/mailman/listinfo/proj4j</a><br>
<br></blockquote></div><br></div>