[PROJ] PROJ 6.1.0RC1
Kristian Evers
kreve at sdfe.dk
Tue May 7 05:50:33 PDT 2019
On 6 May 2019, at 21:21, Sebastiaan Couwenberg <sebastic at xs4all.nl<mailto:sebastic at xs4all.nl>> wrote:
On 5/6/19 8:02 PM, Even Rouault wrote:
...OK, I didn't realize that the failures where not necessarily at the end of the log file...
1) So one failure is:
""""
Test: 01 Texel
Exec: cs2cs EPSG:4937 +to EPSG:28992+5709 -f %.4f
Input: 53.160753042 4.824761912 42.8614
Output: 117380.1203 575040.3399 0.9985
Expect: 117380.1200 575040.3400 1.0000
NAP exceeds 0.001 meters: 0.00149999999999995
Test FAILED: From ETRS89 to RD/NAP - 01 Texel
"""
I will save you the details and headaches, but the gist of the issue was that the vertical transformation
and horizontal transformation where applied in the wrong order.
There were 2 separate causes:
- the EPSG dataset doesn't register the interpolationCRS for "ETRS89 to NAP height (1)" vertical transformation (naptrans2008.gtx).
According to the PDF you provided, this must be the Amersfoort datum. As this information is missing, the code assumes that
the horizontal CRS to use for vertical transformation is ETRS89.
- The code didn't take properly into account the interpolationCRS for such geog3D <--> compoundCRS transformations
I've addressed both issues by the followup commit
https://github.com/OSGeo/proj.4/pull/1454/commits/ae16cff6877a39903cd049491fbb1d96a4149a96
of
https://github.com/OSGeo/proj.4/pull/1454
With that I now get
echo "53.160753042 4.824761912 42.8614" | PROJ_LIB=$PWD:data src/cs2cs -f %.15f EPSG:4937 +to EPSG:7415
117380.120258881375776 575040.339879254694097 1.000069467784584
(instead of the custom compoundCRS "EPSG:28992+5709", you can equivalently use the registered compoundCRS of the EPSG database "EPSG:7415")
That has become quite an impressive PR, thanks!
2) For
"""
Test: 07 No_rd&geoid
Exec: cs2cs EPSG:28992+5709 +to EPSG:4937 -f %.9f
Input: 100000.6700 300000.8900
Output: 50.687420379 4.608971888 0.000000000
Expect: 50.687420405 4.608971812
Latitude exceeds 1e-08 degrees: 2.59999950458223e-08
Longitude exceeds 1e-08 degrees: 7.60000000710193e-08
Test FAILED: From RD/NAP to ETRS89 - 07 No_rd&geoid (Expected output overriden: * * ^-?(\d+\.\d+|inf)$)
"""
PROJ will indeed detect that the point is outside of the RD grid, and then it will use
the EPSG:15739 "Amersfoort to ETRS89 (3)" Helmert-based transformation.
$ echo "100000.6700 300000.8900 0" | src/cct -d 9 +proj=pipeline +step +inv +proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +step +proj=push +v_3 +step +proj=cart +ellps=bessel +step +proj=helmert +x=565.2369 +y=50.0087 +z=465.658 +rx=0.406857330322398 +ry=-0.350732676542563 +rz=1.8703473836068 +s=4.0812 +convention=coordinate_frame +step +inv +proj=cart +ellps=GRS80 +step +proj=pop +v_3 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
50.687420379 4.608971888 0.000000000 inf
I'm not sure how they get their expected result. It should be noted that proj 5.2.0 fails to transform in that case:
$ echo "100000.6700 300000.8900" | ~/proj/install-proj-5.2.0/bin/cs2cs -f %.15f +init=rdnap:rdnap +to +init=epsg:4258
Rel. 5.2.0, September 15th, 2018
<cs2cs>: while processing file: <stdin>, line 1
pj_transform(): point not within available datum shift grids
* * inf
Like test 10 edge_rd, there are coordinates in the output, but exceeding
the margin is ignored to allow the test to succeed. Because as the PDF
documents: "... outside this region RD coordinates can be computed, but
the output should be handled with care.". I don't consider this
indications of issues in proj unlike the failures of the tests within
the RD region. Many thanks for fixing those!
I've added a patch with the changes from #1454 to the proj Debian
package, and with that all the tests succeed again.
Once Travis is happy about the changes, those changes will be included
in RC2?
Yes, Even merged the PR earlier today. I’ll release RC2 later today.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190507/618c5d8d/attachment-0001.html>
More information about the PROJ
mailing list