<div dir="ltr">I tested RC1 with pyproj and all of our tests pass with the current version. Thanks!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 6, 2019 at 2:21 PM Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl">sebastic@xs4all.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/6/19 8:02 PM, Even Rouault wrote:<br>
> ...OK, I didn't realize that the failures where not necessarily at the end of the log file...<br>
> <br>
> 1) So one failure is:<br>
> """"<br>
> Test:   01 Texel<br>
> Exec:   cs2cs EPSG:4937 +to EPSG:28992+5709 -f %.4f<br>
> Input:  53.160753042 4.824761912 42.8614<br>
> <br>
> Output: 117380.1203   575040.3399 0.9985<br>
> Expect: 117380.1200   575040.3400 1.0000<br>
> NAP exceeds 0.001 meters: 0.00149999999999995<br>
> Test FAILED: From ETRS89 to RD/NAP - 01 Texel<br>
> """<br>
> <br>
> I will save you the details and headaches, but the gist of the issue was that the vertical transformation<br>
> and horizontal transformation where applied in the wrong order.<br>
> There were 2 separate causes:<br>
> - the EPSG dataset doesn't register the interpolationCRS for "ETRS89 to NAP height (1)" vertical transformation (naptrans2008.gtx).<br>
>   According to the PDF you provided, this must be the Amersfoort datum. As this information is missing, the code assumes that<br>
>   the horizontal CRS to use for vertical transformation is ETRS89.<br>
> - The code didn't take properly into account the interpolationCRS for such geog3D <--> compoundCRS transformations<br>
> <br>
> I've addressed both issues by the followup commit<br>
> <a href="https://github.com/OSGeo/proj.4/pull/1454/commits/ae16cff6877a39903cd049491fbb1d96a4149a96" rel="noreferrer" target="_blank">https://github.com/OSGeo/proj.4/pull/1454/commits/ae16cff6877a39903cd049491fbb1d96a4149a96</a><br>
> of<br>
> <a href="https://github.com/OSGeo/proj.4/pull/1454" rel="noreferrer" target="_blank">https://github.com/OSGeo/proj.4/pull/1454</a><br>
> <br>
> With that I now get<br>
> <br>
> echo "53.160753042 4.824761912 42.8614" | PROJ_LIB=$PWD:data src/cs2cs -f %.15f EPSG:4937 +to EPSG:7415<br>
> 117380.120258881375776        575040.339879254694097 1.000069467784584<br>
> <br>
> (instead of the custom compoundCRS "EPSG:28992+5709", you can equivalently use the registered compoundCRS of the EPSG database "EPSG:7415")<br>
<br>
That has become quite an impressive PR, thanks!<br>
<br>
> 2) For<br>
> """<br>
> Test:   07 No_rd&geoid<br>
> Exec:   cs2cs EPSG:28992+5709 +to EPSG:4937 -f %.9f<br>
> Input:  100000.6700 300000.8900<br>
> <br>
> Output: 50.687420379  4.608971888 0.000000000<br>
> Expect: 50.687420405  4.608971812<br>
> Latitude exceeds 1e-08 degrees: 2.59999950458223e-08<br>
> Longitude exceeds 1e-08 degrees: 7.60000000710193e-08<br>
> Test FAILED: From RD/NAP to ETRS89 - 07 No_rd&geoid (Expected output overriden: *     * ^-?(\d+\.\d+|inf)$)<br>
> """<br>
> <br>
> PROJ will indeed detect that the point is outside of the RD grid, and then it will use<br>
> the EPSG:15739 "Amersfoort to ETRS89 (3)" Helmert-based transformation. <br>
> <br>
> $ 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<br>
>  50.687420379    4.608971888   0.000000000           inf<br>
> <br>
> 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:<br>
> $ echo "100000.6700 300000.8900" |  ~/proj/install-proj-5.2.0/bin/cs2cs -f %.15f +init=rdnap:rdnap +to +init=epsg:4258 <br>
> Rel. 5.2.0, September 15th, 2018<br>
> <cs2cs>: while processing file: <stdin>, line 1<br>
> pj_transform(): point not within available datum shift grids<br>
> *     * inf<br>
<br>
Like test 10 edge_rd, there are coordinates in the output, but exceeding<br>
the margin is ignored to allow the test to succeed. Because as the PDF<br>
documents: "... outside this region RD coordinates can be computed, but<br>
the output should be handled with care.". I don't consider this<br>
indications of issues in proj unlike the failures of the tests within<br>
the RD region. Many thanks for fixing those!<br>
<br>
I've added a patch with the changes from #1454 to the proj Debian<br>
package, and with that all the tests succeed again.<br>
<br>
Once Travis is happy about the changes, those changes will be included<br>
in RC2?<br>
<br>
Kind Regards,<br>
<br>
Bas<br>
<br>
-- <br>
 GPG Key ID: 4096R/6750F10AE88D4AF1<br>
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font style="font-family:arial,helvetica,sans-serif">Alan Snow</font><br></div></div></div></div></div></div></div></div>