[PROJ] PROJ 6.1.0RC1

[Bas Couwenberg]

On 2019-05-06 11:29, Even Rouault wrote:
>> IIRC epsg:4258 is interpreted as a Geographic 2D CRS which likely 
>> causes
>> the 3D component to be ignored.
> 
> Yes, you should use EPSG:4937 (ETRS89 Geographic 3D CRS), but that will 
> not
> solve the issue with the Z value. 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
> 
> What works however is completely dropping the use of rdnap:rdnap and 
> using
> EPSG:28992+5709 instead, that is "Amersfoort / RD New + NAP height", as 
> there
> is a transformation registered between ETRS89 and NAP height, which 
> uses the
> naptrans2008.gtx grid
> 
> $ echo "53.160753042 4.824761912 42.8614" | \
>       PROJ_LIB=$PWD:data src/cs2cs -f "%.4f" EPSG:4937 EPSG:28992+5709
> 117380.1203	575040.3399 0.9985
> 
> Which is close to what you get with PROJ 5.2.0 with
> cs2cs -r  -f %.4f +init=epsg:4258 +to +init=rdnap:rdnap:
> 117380.1203	575040.3398 1.0000

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.

See the attachment.

>> 
>> The projinfo output is not something I can make sense of, it is as
>> follows:
>> 
>> $ PROJ_LIB=.:/usr/share/proj projinfo -s EPSG:4258 -t rdnap:rdnap
>> target CRS: parsing of user string failed: crs not found
> 
> Note: you can use +init=rdnap:rdnap to resolved in the rdnap file.

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

$ PROJ_LIB=.:/usr/share/proj projinfo -s EPSG:4258 -t +init=rdnap:rdnap
target CRS string is not a CRS

With the updated rdnap init file:

cat rdnap
# RDNAP with NTv2 and VDatum
<rdnap> +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 <>

# RD with NTv2 only
<rd> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
+k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel 
+nadgrids=rdtrans2008.gsb +units=m +no_defs +type=crs <>

We indeed do get results:

$ PROJ_LIB=.:/usr/share/proj projinfo -s EPSG:4258 -t +init=rdnap:rdnap 
| head -8
Candidate operations found: 1
-------------------------------------
Operation n°1:

unknown id, unknown + unknown to WGS84 + Inverse of ETRS89 to WGS 84 (1) 
+ Transformation from unknown to ETRS89 (ballpark vertical 
transformation, without ellipsoid height to vertical height correction), 
unknown accuracy, Europe - ETRS89, has ballpark transformation

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert 
+xy_in=deg +xy_out=rad +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


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

Kind Regards,

Bas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testrdnaptrans2008_epsg4937-epsg28992+5709.log.gz
Type: application/x-gzip
Size: 14895 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190506/09370c8c/attachment-0001.bin>