AW: [Proj] PROJ 4.6.0 beta1 Release

[uwe.schmitz at lverma.nrw.de]

Frank,

> uwe.schmitz at lverma.nrw.de wrote:
> > Frank,
> > 
> > I am using the example from ticket 1531 with a local
> > (may be this is the problem?) grid file (attached
> > to the ticket).
> > 
> > The shell script:
> > export PROJ_DEBUG=1
> > cs2cs \
> >       -f "%.12f" \
> >       +proj=latlong \
> >       +ellps=bessel \
> >       +nadgrids=./tstgrid.gsb \
> >    +to \
> >       +proj=latlong \
> >       +ellps=GRS80 \
> >       <<EOF
> > 7.483333333333E 53.500000000000N
> > EOF
> 
> Uwe,
> 
> But in this case the output coordinate system only has an ellipse, and
> no datum definition, so pj_transform() deliberately makes no 
> attempt to
> do a datum shift.  This is exactly the sort of case in which 
> the behavior
> is intended to change.
> 

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? What also confuses is that the destination
datum isn't really WGS84 in this case, but the slightly 
different 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.

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

Thanks in advance and best regards
Uwe
---------------------------------------------------------
... Uwe Schmitz  Landesvermessungsamt Nordrhein-Westfalen
... Muffendorfer Str. 19 - 21              D - 53177 Bonn
... E-mail:       uwe.schmitzNO at SPAMlverma.nrw.de
... Internet:     http://www.lverma.nrw.de