Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#4416 closed defect (fixed)

Proj 6.0.0 issue on windows - transform: no system list, errno: 22

Reported by: robe Owned by: pramsey
Priority: blocker Milestone: PostGIS 3.0.0
Component: postgis Version: master
Keywords: windows Cc:

Description

I suspect this might be an issue with how the installed system finds the new proj sqlite db. Not sure why this doesn't error out in regress, or maybe because I have proj paths in my regress it works or we are not testing this.

I have this:

POSTGIS="3.0.0alpha2 r17458" [EXTENSION] PGSQL="100" GEOS="3.8.0-CAPI-1.11.0 " PROJ="6.0.0" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)" PostgreSQL 10.1, compiled by Visual C++ build 1800, 64-bit

If I run this:

SELECT ST_Transform(ST_GeomFromText('POINT(1 2)', 4326),4269);

I get an error:

ERROR:  transform: no system list, errno: 22

The proj files I am shipping are in share/contrib/postgis-3.0/proj

and consist of these files

CH
GL27
ITRF2000
ITRF2008
ITRF2014
nad.lst
nad27
nad83
null
other.extra
proj.db
world

I do plan to upgrade to latst proj 6 in a bit just haven't compiled yet but I'm assuming this will still be an issue.

Change History (8)

comment:1 by pramsey, 6 years ago

I'm seeing this on OSX for select projections, like

SELECT ST_Transform('SRID=4326; POINT(0 0)'::geometry, 3906);

this dates to the proj updates recently.

comment:2 by Algunenano, 5 years ago

Is this still an issue or was it fixing after rebuilding?

comment:3 by pramsey, 5 years ago

On my side it's gone away.

comment:4 by robe, 5 years ago

I have to recheck. I have other issues with building with Proj 6 I'm trying to sort out. I think I had no issues with GDAL 2.4 after the last proj release (which I do not compile with proj support). If I try to build PostGIS with GDAL 3.0 (which requires PROJ dependency to Proj 6+) all hell breaks loose. Raster just crashes like crazy if I run against the VC++ builds (I have to double check, but I think is fine under a pure mingw environment). I suspect it's the fact my sqlite somehow depends on libz and GDAL depends on libz (which in the past I just used the internal libz for GDAL but now seems kinda silly if my sqlite is going to be demanding for libz), and that doesn't seem to play well with EDB shipped libz.

pramsey / Algunenano are you building PostGIS with GDAL 3.0? Just curious if you have run into any issues.

comment:5 by Algunenano, 5 years ago

pramsey / Algunenano are you building PostGIS with GDAL 3.0?

I'm building against 3.0 without any issues; beforehand I was building GDAL from source but now I use the distribution packages.

comment:6 by pramsey, 5 years ago

Anyone seeing this still?

comment:7 by robe, 5 years ago

Resolution: fixed
Status: newclosed

nah I have other problems.

comment:8 by robe, 5 years ago

FWIW that test works fine on my 12 mingw64 install now. But I'm still battling dll hell when mixing EDB build with mingw build when shipping (3.0/proj 6). So sadly I may need to ship 2.4 / 5.2 or something until I sort this out.

Note: See TracTickets for help on using tickets.