[Proj4j] ESPG:28992
Gertjan Idema
g.idema at zonnet.nl
Wed Jan 11 18:03:33 EST 2012
Hi Fitz,
I just wrote a test script and can confirm your result.
Then I remembered that there was a difference between proj (c-version)
and proj4j in handling the +towgs parameters.
The c version has some conversion code for parameters 4-7.
Parameters 4-6 get converted from arc seconds to radians.
(param=param*pi/180/3600)
Parameter 7 gets converted from ppm to scaling factor (param=1
+param/1000000)
Here's the code from pj_datum_set.c:
/* transform from arc seconds to radians */
projdef->datum_params[3] *= SEC_TO_RAD;
projdef->datum_params[4] *= SEC_TO_RAD;
projdef->datum_params[5] *= SEC_TO_RAD;
/* transform from parts per million to scaling factor */
projdef->datum_params[6] = (projdef->datum_params[6]/1000000.0) + 1;
This code seems to be missing in proj4j.
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
Applying the above calculation to the last 4 parameters as a work around
gives:
+towgs84=565.237,50.0087,465.658,-1.972e-6,1.7004e-6,-9.0677e-6,1.0000040812
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.
I get 155029.79163595638 463109.9538034333 for your reference point
instead.
However, the result seems to agree with some other data I have. I'll do
some more research tomorrow.
Gertjan Idema
On Wed, 2012-01-11 at 09:51 -0400, jeff fitzgerald 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
>
> On Wed, Jan 11, 2012 at 9:41 AM, Gertjan Idema <g.idema at zonnet.nl>
> wrote:
>
> I haven't seen this, but then I haven't used proj4j for a
> while.
> The result you give for proj4j is definitely wrong. Any valid
> EPSG:28992 coordinate has x<y .
>
> Gertjan
>
>
> On Wed, 2012-01-11 at 09:09 -0400, jeff fitzgerald wrote:
>
> > Hey Martin,
> >
> > There just seems to be a big discrepancy for me between proj
> > and proj4j.
> >
> > Using the string with the tows84 method and
> > 5.387638889,52.156160556 as my test point,
> > - Proj gives me 154976.16420640881,463086.51164757559
> > - proj4j gives me x = 4761867.817294979 y =
> > 2527483.7229957823
> >
> > Does anyone else get similar results?
> >
> > Thanks.
> >
> > Fitz
> >
> > On Tue, Jan 10, 2012 at 1:13 AM, Martin Davis
> > <mtnclimb at gmail.com> wrote:
> >
> > Some more information on this issue.
> >
> > The addition of the towgs84 parameter happened last
> > August, as a result of this ticket:
> >
> > http://trac.osgeo.org/proj/ticket/96
> >
> > The SVN version of EPSG:28992 has the +towgs
> > parameter, whereas the version in the PROJ.4 distro
> > archive does not.
> >
> > 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:
> >
> > http://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/
> >
> > Out of curiousity, what are the issues that you're
> > seeing with this new definition?
> >
> >
> > On Mon, Jan 9, 2012 at 8:16 AM,
> > <jeffery.fitzgerald at gmail.com> wrote:
> >
> >
> > Hey,
> >
> > I noticed that the epsg file that ships with
> > proj4j has a different entry for ESPG:28992
> > than I have seen in proj.
> >
> > proj4j epsg
> > # Amersfoort / RD New
> > <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 <>
> >
> > gdal epsg
> > # Amersfoort / RD New
> > <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 <>
> >
> > Does anyone know why? It was causing me some
> > trouble until I removed the towgs84.
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Proj4j mailing list
> > Proj4j at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/proj4j
> >
> >
> >
> >
> > _______________________________________________
> > Proj4j mailing list
> > Proj4j at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/proj4j
>
>
>
>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/proj4j/attachments/20120112/6f5c74a5/attachment-0001.html
More information about the Proj4j
mailing list