[PROJ] PROJ 6.0.0 cs2cs: cannot instantiate source coordinate system - program abnormally terminated

[Even Rouault]

On vendredi 8 mars 2019 18:39:30 CET Sebastiaan Couwenberg wrote:
> On 3/8/19 6:17 PM, Even Rouault wrote:
> > On vendredi 8 mars 2019 16:28:07 CET Sebastiaan Couwenberg wrote:
> >> The cs2cs tests in the proj-rdnap package [0] fail with PROJ 6.0.0:
> >>  Rel. 6.0.0, March 1st, 2019
> >>  <cs2cs>:
> >>  cannot initialize transformation
> >>  cause: (null)
> >>  program abnormally terminated
> >> 
> >> The problem seems to be the minimal epsg file in PROJ_LIB, removing is
> >> works around the issue.
> >> 
> >> Should cs2cs really terminate abnormally when an problematic init file
> >> is present in PROJ_LIB?
> > 
> > Actually, this is rather subtle. The issue is that the definition of
> > epsg:4258 in the minimum epsg file is interpretated as a Geographic 2D
> > CRS, whereas rdnap:rdnap is interpretated as as CompoundCRS (horizontal +
> > vertical). Normally the code that computes the possible transformation
> > paths would find a Geographic 3D CRS that corresponds to the Geographic
> > 2D CRS, but in the case of a '+proj=longlat +ellps=GRS80
> > +towgs84=0,0,0,0,0,0,0 +no_defs' definition, there's no single such 3D
> > CRS. So no transformation path is returned at all.
> > 
> > When using the EPSG:4258 definition from proj.db, then the EPSG:4937
> > (ETRS89 3D) is used internally.
> 
> So if I understand correctly, the abnormal termination is expected and
> not a bug.
> 
> Having updated the RDNAP test script for PROJ 6.0.0, all test test still
> fail because the output for the transformation exceeds the threshold.
> 
> Are these large differences expected too when using PROJ 6.0.0?

They look like the datum shifts are not applied.

Yes, when testing

src/projinfo -s EPSG:4258  -t "+proj=sterea +lat_0=52.15616055555555 
+lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel 
+nadgrids=@rdtrans2008.gsb +geoidgrids=@naptrans2008.gtx +units=m +no_defs 
+type=crs"

we get

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert 
+xy_in=deg +xy_out=rad +step +proj=sterea +lat_0=52.1561605555556 
+lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel


So the nadgrids and geoidgrids terms are ignored. The reason here is that they 
are used as a hint for transformations to WGS84, but EPSG:4258 definition 
doesn't include any such explicit transformation with a towgs84/geoidgrids/
nadgrids. So we are in a grey situation that is neither a pure late-binding or 
pure early-binding situation. Opinions welcome if in such a situation where 
there is a early binding style CRS we should try hard to research a 
transformation from the other CRS to WGS84.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com