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

[Lesparre, Jochem]

Hi Even,

What is unclear here? I still don't understand the early and late binding terminology so I can't understand your explanation.
The RD and NAP grid files are correct for transformation to ETRS89 not for transformation to WGS84.

Regards, Jochem

-----Original Message-----
From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Even Rouault
Sent: Saturday, March 9, 2019 8:36 PM
To: proj at lists.osgeo.org
Cc: Sebastiaan Couwenberg <sebastic at xs4all.nl>
Subject: Re: [PROJ] PROJ 6.0.0 cs2cs: cannot instantiate source coordinate system - program abnormally terminated

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
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj


Disclaimer:
De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster 
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u 
dit direct te melden aan de verzender en het bericht te vernietigen. 
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.

Disclaimer:
The content of this message is meant to be received by the addressee only.
Use of the content of this message by anyone other than the addressee without the consent 
of the Kadaster is unlawful. If you have received this message, but are not the addressee, 
please contact the sender immediately and destroy the message.
No rights can be derived from the content of this message