[PROJ] PROJ 6.1.0RC1

[Even Rouault]

>>  The issue here is that in the
> > rdnap:rdnap
> > string, the +geoidgrids=naptrans2008.gtx implies a transformation
> > between
> > WGS84 3D and the vertical CRS implied by naptrans2008.gtx. But you want
> > to
> > transform between ETRS89 3D and that vertical CRS. As there is no
> > transformation registered in the EPSG dataset between WGS84 3D and
> > ETRS89 3D
> > (there is one only on the 2D part), PROJ cannot use the vertical grid

I've prepared a fix in https://github.com/OSGeo/proj.4/pull/1454 for that 
particular case (it turns out that something in the monster I created still 
manages to use the 2D ETRS89<-->WGS84 transformation):

$ src/projinfo -s EPSG:4937 -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 +type=crs 
+no_defs" -o PROJ

Candidate operations found: 1
-------------------------------------
Operation n°1:

unknown id, unknown + unknown to WGS84 + Inverse of ETRS89 to WGS 84 (1) + 
unknown to WGS84 ellipsoidal height + Inverse of ETRS89 to WGS 84 (1), unknown 
accuracy, Europe - ETRS89, at least one grid missing

PROJ string:
+proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step 
+proj=axisswap +order=2,1 +step +inv +proj=vgridshift +grids=naptrans2008.gtx 
+multiplier=1 +step +inv +proj=hgridshift +grids=rdtrans2008.gsb +step 
+proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889 +k=0.9999079 
+x_0=155000 +y_0=463000 +ellps=bessel

So both grids are used.

> 
> Using epsg:4937 & epsg:28992+5709 doesn't fix the test failures, while
> the debug output is more extensive, I don't see naptrans2008.gtx being
> used, only rdtrans2008.gsb.

OK, I see in the log that you use
Exec:   cs2cs -r +init=epsg:4937 +to +init=epsg:28992+5709 -f %.4f

Just try (without the -r flag and the +init=epsg: prefixes):
cs2cs EPSG:4937 EPSG:28992+5709 -f %.4f

using the +init=epsg: syntax will go in a compatibility mode where the CRS 
will be expanded as a PROJ string as was done in the past, and thus you loose  
information about datums.

> Thanks for the tip. The syntax needs to be changed to include +type=crs
> I guess, because it still fails:

Yes, you need to add +type=crs to disambiguish the case where PROJ strings 
express CRS or coordinate operations

> That leads to the question: How backwards compatible is +type=crs?

Older PROJ versions should happily ignore it.

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