AW: [Proj] PROJ 4.6.0 beta1 Release

[Frank Warmerdam]

uwe.schmitz at lverma.nrw.de wrote:
> oh yes, my fault! It shows me that I didn't really understand
> what I'm doing with PROJ.4 :-)
> 
> OK, if I add "+datum=WGS84" to the "+to" part I get the same
> result as with V4.5.0 (still wrong in respect of ticket 1531).
> Despite that, isn't it true that the grid file contains 
> datum definition for both (from and to) system?  So isn't
> it better to assume datum definition for both systems, if
> a grid is specified? 

Uwe,

PROJ.4 implicitly assumes that datum grids map from the
local datum to WGS84 but the output coordinate system can
be other than WGS84 so I don't agree that the nadgrids
implies the whole transformation.

 > What also confuses is that the destination
> datum isn't really WGS84 in this case, but the slightly 
> different ETRS89.

Because the PROJ nadgrids directive does not understand that
there can exist grids going to coordinate systems other than
WGS84 it is necessary to fool it. So you declare your output
coordinate system as +datum=WGS84 but *you* know that you want
to inteprete the output coordinates as ETRS89.

> Anyhow, I think the change breaks backward compatibility and this
> has to be documented very well. All of my old scripts have to 
> be patched to give the right results.

Getting to your core problem, I stepped through the code and found
that PROJ is not attempting to apply a bessel to WGS84 ellipsoid
change in your case.   After the gridshift file is applied it
internally updates it's concept of source ellipsoid to be WGS84.

Unfortunately, it uses a WGS84 "es" value that is slightly different
than the one that results from +datum=WGS84 so it thinks the
input and output coordinate system still have different ellipsoids
and it goes through geocentric space to correct this.  I have modified
pj_transform.c to use the same WGS84 es value that is used with
+datum=WGS84 and now this processing is avoided, and your exact expected
output value is produced again.  This change will appear in beta2.

Thanks for highlighting the bug 1531 issue.

> Another question: When an how do these changes affect GDAL/OGR?

GDAL/OGR uses PROJ.4 for transformations and so the change also
applies to GDAL/OGR (and MapServer, GRASS, etc).  For the most
part it should mean people no longer need to be hyper-aware of
the interals of PROJ as things will start to work the way folks
expect.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org