[Proj4j] ESPG:28992

Wed Jan 11 18:33:33 EST 2012

Great that you're looking into this, guys.

If you can confirm that those parameter conversions need to happen, I'm
happy to add them.

On Wed, Jan 11, 2012 at 3:03 PM, Gertjan Idema <g.idema at zonnet.nl> wrote:

> **
> 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 listProj4j at lists.osgeo.orghttp://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/20120111/4dc8045c/attachment.html