[PROJ] PROJ 6.1.0RC1

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] PROJ 6.1.0RC1

Kristian Evers-2
I have prepared candidates for the upcoming releases of PROJ 6.1.0 and proj-datumgrid-europe-1.3.

Download the archives here:




Please test the release candidates and report back any problems you may find. If no issues
are discovered I plan to call the vote for promotion to final release on Monday May 13th with
a targeted release date at May 15th.

/Kristian



_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan Couwenberg
[Resending with compressed attachment]

On 2019-05-06 08:24, Kristian Evers wrote:
> Please test the release candidates and report back any problems you
> may find.

The tests for the RDNAP datumgrid [0] still fail with 6.1.0-rc1.

The height values are exceed the allowed margin. See the attachment.

This is the biggest regression since PROJ 5.2.0 I've encountered.

[0] https://lists.osgeo.org/pipermail/proj/2019-March/008313.html

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

testrdtrans2008.log.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Kristian Evers-2
From the previous thread it seems to be a difficult problem without a clear
Solution. Looking at the test output though it seems as if the vertical shift
isn't  applied. Whether that is because of the issues discussed previously or
it is a problem in finding the naptrans2008.gtx grid on the system I can't
tell from the log file.

The log file is also reporting that the epsg init file fails to load:

        pj_open_lib(epsg): call fopen(/usr/share/proj/epsg) - failed

So, is this simply an incorrect setting of PROJ_LIB or is it still the same
not so simple issue as reported previously?

/Kristian

-----Oprindelig meddelelse-----
Fra: PROJ <[hidden email]> På vegne af Bas Couwenberg
Sendt: 6. maj 2019 09:42
Til: [hidden email]
Emne: Re: [PROJ] PROJ 6.1.0RC1

[Resending with compressed attachment]

On 2019-05-06 08:24, Kristian Evers wrote:
> Please test the release candidates and report back any problems you
> may find.

The tests for the RDNAP datumgrid [0] still fail with 6.1.0-rc1.

The height values are exceed the allowed margin. See the attachment.

This is the biggest regression since PROJ 5.2.0 I've encountered.

[0] https://lists.osgeo.org/pipermail/proj/2019-March/008313.html

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan Couwenberg
On 2019-05-06 10:08, Kristian Evers wrote:

> From the previous thread it seems to be a difficult problem without a
> clear
> Solution. Looking at the test output though it seems as if the vertical
> shift
> isn't  applied. Whether that is because of the issues discussed
> previously or
> it is a problem in finding the naptrans2008.gtx grid on the system I
> can't
> tell from the log file.
>
> The log file is also reporting that the epsg init file fails to load:
>
> pj_open_lib(epsg): call fopen(/usr/share/proj/epsg) - failed

This is expected, because the epsg init file no longer exist for PROJ 6.

The minimal epsg init file is also moved out of the way to prevent it
from being used, this file was used with prior versions that only
supporting a single path in PROJ_LIB.

> So, is this simply an incorrect setting of PROJ_LIB or is it still the
> same
> not so simple issue as reported previously?

It's probably the not so simple issue.

IIRC epsg:4258 is interpreted as a Geographic 2D CRS which likely causes
the 3D component to be ignored.

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

$ PROJ_LIB=.:/usr/share/proj projinfo -s EPSG:4258 -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 +no_defs +type=crs"
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

WKT2_2018 string:
COORDINATEOPERATION["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)",
     SOURCECRS[
         GEOGCRS["ETRS89",
             DATUM["European Terrestrial Reference System 1989",
                 ELLIPSOID["GRS 1980",6378137,298.257222101,
                     LENGTHUNIT["metre",1]]],
             PRIMEM["Greenwich",0,
                 ANGLEUNIT["degree",0.0174532925199433]],
             CS[ellipsoidal,2],
                 AXIS["geodetic latitude (Lat)",north,
                     ORDER[1],
                     ANGLEUNIT["degree",0.0174532925199433]],
                 AXIS["geodetic longitude (Lon)",east,
                     ORDER[2],
                     ANGLEUNIT["degree",0.0174532925199433]],
             ID["EPSG",4258]]],
     TARGETCRS[
         COMPOUNDCRS["unknown",
             BOUNDCRS[
                 SOURCECRS[
                     PROJCRS["unknown",
                         BASEGEOGCRS["unknown",
                             DATUM["Unknown based on Bessel 1841
ellipsoid",
                                 ELLIPSOID["Bessel
1841",6377397.155,299.1528128,
                                     LENGTHUNIT["metre",1,
                                         ID["EPSG",9001]]]],
                             PRIMEM["Greenwich",0,
                                 ANGLEUNIT["degree",0.0174532925199433],
                                 ID["EPSG",8901]]],
                         CONVERSION["unknown",
                             METHOD["Oblique Stereographic",
                                 ID["EPSG",9809]],
                             PARAMETER["Latitude of natural
origin",52.1561605555556,
                                 ANGLEUNIT["degree",0.0174532925199433],
                                 ID["EPSG",8801]],
                             PARAMETER["Longitude of natural
origin",5.38763888888889,
                                 ANGLEUNIT["degree",0.0174532925199433],
                                 ID["EPSG",8802]],
                             PARAMETER["Scale factor at natural
origin",0.9999079,
                                 SCALEUNIT["unity",1],
                                 ID["EPSG",8805]],
                             PARAMETER["False easting",155000,
                                 LENGTHUNIT["metre",1],
                                 ID["EPSG",8806]],
                             PARAMETER["False northing",463000,
                                 LENGTHUNIT["metre",1],
                                 ID["EPSG",8807]]],
                         CS[Cartesian,2],
                             AXIS["(E)",east,
                                 ORDER[1],
                                 LENGTHUNIT["metre",1,
                                     ID["EPSG",9001]]],
                             AXIS["(N)",north,
                                 ORDER[2],
                                 LENGTHUNIT["metre",1,
                                     ID["EPSG",9001]]]]],
                 TARGETCRS[
                     GEOGCRS["WGS 84",
                         DATUM["World Geodetic System 1984",
                             ELLIPSOID["WGS 84",6378137,298.257223563,
                                 LENGTHUNIT["metre",1]]],
                         PRIMEM["Greenwich",0,
                             ANGLEUNIT["degree",0.0174532925199433]],
                         CS[ellipsoidal,2],
                             AXIS["latitude",north,
                                 ORDER[1],
                                 ANGLEUNIT["degree",0.0174532925199433]],
                             AXIS["longitude",east,
                                 ORDER[2],
                                 ANGLEUNIT["degree",0.0174532925199433]],
                         ID["EPSG",4326]]],
                 ABRIDGEDTRANSFORMATION["unknown to WGS84",
                     METHOD["NTv2",
                         ID["EPSG",9615]],
                     PARAMETERFILE["Latitude and longitude difference
file","rdtrans2008.gsb",
                         ID["EPSG",8656]]]],
             BOUNDCRS[
                 SOURCECRS[
                     VERTCRS["unknown",
                         VDATUM["unknown"],
                         CS[vertical,1],
                             AXIS["gravity-related height (H)",up,
                                 LENGTHUNIT["metre",1,
                                     ID["EPSG",9001]]]]],
                 TARGETCRS[
                     GEOGCRS["WGS 84",
                         DATUM["World Geodetic System 1984",
                             ELLIPSOID["WGS 84",6378137,298.257223563,
                                 LENGTHUNIT["metre",1]]],
                         PRIMEM["Greenwich",0,
                             ANGLEUNIT["degree",0.0174532925199433]],
                         CS[ellipsoidal,3],
                             AXIS["latitude",north,
                                 ORDER[1],
                                 ANGLEUNIT["degree",0.0174532925199433]],
                             AXIS["longitude",east,
                                 ORDER[2],
                                 ANGLEUNIT["degree",0.0174532925199433]],
                             AXIS["ellipsoidal height",up,
                                 ORDER[3],
                                 LENGTHUNIT["metre",1]],
                         ID["EPSG",4979]]],
                 ABRIDGEDTRANSFORMATION["unknown to WGS84 ellipsoidal
height",
                     METHOD["GravityRelatedHeight to Geographic3D"],
                     PARAMETERFILE["Geoid (height correction) model
file","naptrans2008.gtx",
                         ID["EPSG",8666]]]]]],
     METHOD["PROJ-based operation method (approximate): +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"],
     USAGE[
         SCOPE["unknown"],
         AREA["Europe - ETRS89"],
         BBOX[32.88,-16.1,84.17,40.18]]]

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Even Rouault-2
Bas,

> 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

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

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan 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

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

testrdnaptrans2008_epsg4937-epsg28992+5709.log.gz (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Even Rouault-2
>>  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
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan 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
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

testrdnaptrans2008_epsg4937-epsg28992+5709_no+init.log.gz (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

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

yes, no impact

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

ok, so this is on

Test:   10 edge_rd
Exec:   cs2cs EPSG:28992+5709 +to EPSG:4937 -f %.9f
Input:  50000.4500 335999.6700
[...]
Output: 51.003976841 3.891248343 44.739810857
Expect: 51.003976532 3.891247830
Latitude exceeds 1e-08 degrees: 3.08999993592352e-07
Longitude exceeds 1e-08 degrees: 5.12999999813246e-07

With proj 5.2.0:
$ echo "50000.4500 335999.6700" | ~/proj/install-proj-5.2.0/bin/cs2cs  
+init=rdnap:rdnap +to +init=epsg:4258 -f %.9f
3.891248343 51.003976842 44.740002097

And with proj master/6.1
$ echo "50000.4500 335999.6700" | PROJ_LIB=$PWD:data src/cs2cs EPSG:28992+5709
+to EPSG:4937 -f %.9f
51.003976841 3.891248343 44.739810857

So for lat,long I get almost the same values with both PROJ versions (1e-9 deg
difference on latitude). Perhaps the test expected result should be updated ?

Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan Couwenberg
On 2019-05-06 15:05, Even Rouault wrote:

>> Removing the cs2cs args and +init= prefix result in the gtx being
>> used,
>> but the magin is still too large.
>>
>> See the attachment.
>
> ok, so this is on
>
> Test:   10 edge_rd
> Exec:   cs2cs EPSG:28992+5709 +to EPSG:4937 -f %.9f
> Input:  50000.4500 335999.6700
> [...]
> Output: 51.003976841 3.891248343 44.739810857
> Expect: 51.003976532 3.891247830
> Latitude exceeds 1e-08 degrees: 3.08999993592352e-07
> Longitude exceeds 1e-08 degrees: 5.12999999813246e-07
>
> With proj 5.2.0:
> $ echo "50000.4500 335999.6700" | ~/proj/install-proj-5.2.0/bin/cs2cs
> +init=rdnap:rdnap +to +init=epsg:4258 -f %.9f
> 3.891248343 51.003976842 44.740002097
>
> And with proj master/6.1
> $ echo "50000.4500 335999.6700" | PROJ_LIB=$PWD:data src/cs2cs
> EPSG:28992+5709
> +to EPSG:4937 -f %.9f
> 51.003976841 3.891248343 44.739810857
>
> So for lat,long I get almost the same values with both PROJ versions
> (1e-9 deg
> difference on latitude). Perhaps the test expected result should be
> updated ?

Tests 07 - 10 are already handled differently, the "Use of RDTRANS2008
and NAPTRANS2008.pdf" [0] documents the following:

"
    Points 07 - 10 are outside the region where interpolation between
    either the NLGEO2004 geoid or the RD correction grid points is
    possible. RD is defined only within the region enclosed by the
    following points (in RD), outside this region RD coordinates can
    be computed, but the output should be handled with care.

    Corners of the validity region for RD:
    ┌────────┬────────┐
    │  x (m) │  y (m) │
    ├────────┼────────┤
    │ 140000 │ 630000 │
    │ 100000 │ 600000 │
    │  80000 │ 500000 │
    │  -8000 │ 390000 │
    │  -8000 │ 335000 │
    │ 100000 │ 335000 │
    │ 160000 │ 288000 │
    │ 220000 │ 288000 │
    │ 301000 │ 450000 │
    │ 301000 │ 615000 │
    │ 260000 │ 630000 │
    └────────┴────────┘
"

The other tests (01 - 06) should all pass with values within the allowed
margin of those expected.

Appendix 2 of the PDF documents the following:

"
  The transformation between ETRS89 and RD/NAP procedure should be tested
in both directions. The
  rdtrans2008.gsb consists of one parent grid and one child grid, the
naptrans2008.gtx consists of one
  grid, the bounding boxes of the grids, in Bessel-1841 geographic
coordinates, are given by:

                      NTv2-parent grid  NTv2-child grid  VDatum-grid
  Latitude Minimum    50° 30’ 00.000”   50° 30’ 00.000”  50° 30’ 00.000”
  Latitude Maximum    55° 50’ 00.000”   54° 00’ 00.000”  55° 50’ 00.000”
  Latitude Interval   00° 05’ 00.000”   00° 00’ 30.000”  00° 00’ 30.000”
  Longitude Minimum   02° 30’ 00.000”   03° 00’ 00.000”  02° 30’ 00.000”
  Longitude Maximum   07° 40’ 00.000”   07° 40’ 00.000”  07° 40’ 00.000”
  Longitude Interval  00° 05’ 00.000”   00° 00’ 30.000”  00° 01’ 00.000”

  The coordinates below are computed with the RDNAPTRANSTM2008. the
differences when using the
  rdtrans2008.gsb and naptrans2008.gtx grids should not exceed, except
for point 10 (see limitation 2)
  of the rdtrans2008 NTv2-grid):

  RD x and y coordinates:                      0.001 meters
  NAP heights and ETRS89 ellipsoidal heights:  0.001 meters
  ETRS89 latitude and longitude:               0.00000001 degrees
"

This margin was not exceeded with PROJ 5.2.0 (for tests 01 - 06).

[0]
https://salsa.debian.org/debian-gis-team/proj-rdnap/blob/debian/2008-8/Use%20of%20RDTRANS2008%20and%20NAPTRANS2008.pdf

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan Couwenberg
On 5/6/19 3:22 PM, Bas Couwenberg wrote:
> This margin was not exceeded with PROJ 5.2.0 (for tests 01 - 06).

For comparison, see the output of the test script for 5.2.0 & 6.1.0rc1
in the attachments.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

testrdnaptrans2008_proj-5.2.0.log (6K) Download Attachment
testrdnaptrans2008_proj-5.2.0_6.1.0rc1.diff (10K) Download Attachment
testrdnaptrans2008_proj-6.1.0rc1.log (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Even Rouault-2
In reply to this post by Sebastiaan Couwenberg
...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")

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

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Even Rouault-2
>- 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.

OK, I just submitted a change request to EPSG for that. But I then realized
that currently the EPSG database itself doesn't even have a column for the
interpolationCRS. This is a PROJ-only addition when I aligned the database
model on ISO-19111. So I guess that the manual patching I did will remain for
some time until EPSG upgrades their data model.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Sebastiaan Couwenberg
In reply to this post by Even Rouault-2
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?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Alan Snow
I tested RC1 with pyproj and all of our tests pass with the current version. Thanks!

On Mon, May 6, 2019 at 2:21 PM Sebastiaan Couwenberg <[hidden email]> 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?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


--
Alan Snow

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 6.1.0RC1

Kristian Evers-2
In reply to this post by Sebastiaan Couwenberg


On 6 May 2019, at 21:21, Sebastiaan Couwenberg <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj