Opened 5 years ago
Closed 5 years ago
#4642 closed defect (fixed)
regress_proj test fails with PROJ 7.0.0
| Reported by: | Bas Couwenberg | Owned by: | pramsey |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 3.0.2 |
| Component: | postgis | Version: | 3.0.x |
| Keywords: | Cc: |
Description
The Debian package of PostGIS 3.0.0 failed to build with PROJ 7.0.0-RC1 due to a test failure:
regress_proj .. failed (diff expected obtained: /tmp/pgis_reg/test_80_diff) ----------------------------------------------------------------------------- --- regress_proj_expected 2019-10-20 02:26:04.000000000 +0000 +++ /tmp/pgis_reg/test_80_out 2020-02-19 06:58:31.272205393 +0000 @@ -11,4 +11,4 @@ 10|POINT(574600 5316780) 11|SRID=100001;POINT(574600 5316780) ERROR: could not parse proj string 'invalid projection' -13|150 +ERROR: transform: failed to load datum shift file (-38) -----------------------------------------------------------------------------
Change History (11)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
I've built Proj master with Datumgrid 1.8 and it passes all the tests.
PROJ4 version: 70
I see in the release notes (https://lists.osgeo.org/pipermail/proj/2020-February/009381.html) that it has switched to use proj-data. I'm trying to download proj-data but the download speed is pretty low and it's taking quite a bit of time.
I couldn't find exactly what to do with the file once I get it, I guess place the contents under /nad?
comment:3 by , 5 years ago
I've built Proj master with Datumgrid 1.8 and it passes all the tests.
Can you identify the commit that fixes regress_proj?
I couldn't find exactly what to do with the file once I get it, I guess place the contents under /nad?
The grids from proj-datumgrid-1.8 should be unpacked in the data subdirectory of the proj source tree, as some of these grids are required for make check.
The content of the proj-data archives, like the regional proj-datumgrid archive (e.g. proj-datumgrid-europe) should just be unpacked into the data directory after PROJ is installed as documented in README.DATA:
The files in this package are in cloud-optimized GeoTIFF format and can be unpacked in the PROJ data directory of PROJ 7 or later. For an installed PROJ this may be /usr/local/share/proj or /usr/share/proj on unix style operating systems.
Having the proj-data content installed locally avoids the need to fetch these grids from the CDN.
comment:4 by , 5 years ago
Can you identify the commit that fixes regress_proj?
I didn't change anything in master. Just built a clean package with datum-grid.
The grids from proj-datumgrid-1.8 should be unpacked in the data subdirectory of the proj source tree, as some of these grids are required for make check.
Yes, for the first test I didn't change anything from my previous proj 6 build. I generated a package pointing to PROJ/master/HEAD by first decompressing proj-datumgrid-1.8 into proj/nad.
The content of the proj-data archives, like the regional proj-datumgrid archive (e.g. proj-datumgrid-europe) should just be unpacked into the data directory after PROJ is installed as documented in README.DATA:
The files in this package are in cloud-optimized GeoTIFF format and can be unpacked in the PROJ data directory of PROJ 7 or later. For an installed PROJ this may be /usr/local/share/proj or /usr/share/proj on unix style operating systems.
Having the proj-data content installed locally avoids the need to fetch these grids from the CDN.
Yep, once I downloaded proj-data-1.0RC1.tar.gz y added a step in my package to decompress the data into "${pkgdir}"/usr/share/"${_pkgname}" (and removed the datumgrid step) to have it all inside a single package.
With that I also get the same error as the one reported:
$ cat /tmp/pgis_reg/test_80_diff --- regress_proj_expected 2020-01-24 17:02:17.881733326 +0100 +++ /tmp/pgis_reg/test_80_out 2020-02-21 11:22:44.202677692 +0100 @@ -11,4 +11,4 @@ 10|POINT(574600 5316780) 11|SRID=100001;POINT(574600 5316780) ERROR: could not parse proj string 'invalid projection' -13|150 +ERROR: transform: failed to load datum shift file (-38)
The test that is failing is just iterating over the 150 first crcs to overflow the transformation cache that we keep internally, so it is likely that one of them has lost support in the shift from datum-grid to proj-data.
I'll try to narrow it down.
comment:5 by , 5 years ago
The offending SRID is 4138:
ELECT ST_AsEWKT(ST_Transform('SRID=4326; POINT(0 0)'::geometry, 4138));
ERROR: transform: failed to load datum shift file (-38)
Select * from spatial_ref_sys where srid = 4138;
srid | auth_name | auth_srid |
srtext
| proj4text
------+-----------+-----------+----------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------+---------------------------------------
4138 | EPSG | 4138 | GEOGCS["St. George Island",DATUM["St_George_Island",SPHEROID["Clarke 1866",6378206.4,294.9786
982138982,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6138"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.
0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4138"]] | +proj=longlat +ellps=clrk66 +no_defs
(1 row)
With PROJ6 and datum-grid:
SELECT ST_AsEWKT(ST_Transform('SRID=4326; POINT(0 0)'::geometry, 4138));
st_asewkt
------------------------------------
SRID=4138;POINT(Infinity Infinity)
(1 row)
I don't know if that was transformation is even supposed to work.
comment:6 by , 5 years ago
Same for 4137:
template_postgis=# SELECT srid FROM spatial_ref_sys WHERE srid != 4138 LIMIT 1 offset 69;
srid
------
4137
(1 row)
template_postgis=# Select * from spatial_ref_sys where srid = 4137;
srid | auth_name | auth_srid |
srtext
| proj4text
------+-----------+-----------+----------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------+---------------------------------------
4137 | EPSG | 4137 | GEOGCS["St. Paul Island",DATUM["St_Paul_Island",SPHEROID["Clarke 1866",6378206.4,294.97869821
38982,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6137"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174
532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4137"]] | +proj=longlat +ellps=clrk66 +no_defs
And 4136: template_postgis=# SELECT ST_AsEWKT(ST_Transform('SRID=4326; POINT(0 0)'::geometry, 4136)); ERROR: transform: failed to load datum shift file (-38) template_postgis=# Select * from spatial_ref_sys where srid = 4136;
srid | auth_name | auth_srid |
srtext
| proj4text
4136 | EPSG | 4136 | GEOGCS["St. Lawrence Island",DATUM["St_Lawrence_Island",SPHEROID["Clarke 1866",6378206.4,294.
9786982138982,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6136"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree ",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4136"]] | +proj=longlat +ellps=clrk66 +no_defs (1 row)
comment:7 by , 5 years ago
| Milestone: | PostGIS 3.0.1 → PostGIS next |
|---|
comment:9 by , 5 years ago
Reported the change in behaviour upstream: https://github.com/OSGeo/PROJ/issues/1973
The same error occurs with PostGIS 3.1.0-alpha1.