[PROJ] PROJ 6.1.0RC1

[Bas Couwenberg]

On 2019-05-06 12:59, Even Rouault wrote:
>>>  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.

This change should have no impact when using EPSG:28992+5709 instead of 
+init=rdnap:rdnap, right?

>> 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.

Removing the cs2cs args and +init= prefix result in the gtx being used, 
but the magin is still too large.

See the attachment.

>> 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.

Thanks for the clarification. For now I've updated the test script to 
use EPSG:28992+5709 instead of +init=rdnap:rdnap, using the latter only 
for PROJ < 6.

Kind Regards,

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