No WFS support for OGR FDW under Windows

[davis]

Installed PostGIS 3.0.0 using StackBuilder for the EnterpriseDb Windows PostgreSQL distribution. Added extensions postgis and ogr_fdw. Creation of a foreign server using WFS results in an error:

ERROR:  unable to find format "WFS"
HINT:  See the formats list at http://www.gdal.org/ogr_formats.html
SQL state: HV00N

[robe]

davis can you let me know which version of PostgreSQL you are using?

SELECT version();
SELECT postgis_full_version(); 

Sounds like I might have accidentally left out the curl dependency.

[robe]

Okay I was able to replicate the issue on my:

PostgreSQL 12.1, compiled by Visual C++ build 1914, 64-bit POSTGIS="3.0.0 r17983" [EXTENSION] PGSQL="120" GEOS="3.8.0-CAPI-1.13.1 " PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.4.3, released 2019/10/28" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)" TOPOLOGY RASTER

doing

CREATE SERVER geoserver
		FOREIGN DATA WRAPPER ogr_fdw
		OPTIONS (
datasource 'WFS:https://demo.geo-solutions.it/geoserver/wfs',
format 'WFS' );

[davis]

PostgreSQL 12.1, compiled by Visual C++ build 1914, 64-bit

POSTGIS="3.0.0 r17983" [EXTENSION] PGSQL="120" GEOS="3.8.0-CAPI-1.13.1 " PROJ="Rel. 5.2.0, September 15th, 2018" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)"

[robe]

Can you replace your gdal-20.dll in your C:/Program Files/PostgreSQL/12/bin folder with the one in this zip

​https://winnie.postgis.net/download/windows/pg12/buildbot/extras/gdal_2.4.3-with-curl.zip

LONG ANSWER AS TO THE ISSUE

I haven't repackaged the ogr_fdw with this cause I'm still having issue when doing this:

— the unsafessl is so it doesn't bother checking ssl cert, so I don't have to set that as env

CREATE SERVER geoserver
		FOREIGN DATA WRAPPER ogr_fdw
		OPTIONS (
datasource 'WFS:https://demo.geo-solutions.it/geoserver/wfs',
format 'WFS', config_options 'GDAL_HTTP_UNSAFESSL=yes' );

But it recognizes the curl now but is giving an EPSG error

ERROR:  GDAL NotSupported [6] EPSG PCS/GCS code 404000 not found in EPSG support files.  Is this a valid EPSG coordinate system?
SQL state: XX000

So I think that's an unrelated issue. I tried with my state government (which I know used to work eons ago when I tested)

WFS:https://giswebservices.massgis.state.ma.us/geoserver/wfs?service=WFS&version=1.0.0

and get the same error with same specific complaint about this particular EPSG

I looked in the pcs.csv file in C:/Program Files/PostgreSQL/12/gdal-data/pcs.csv and can't find this code listed there. So not sure if maybe its a new GeoServer one or something different with GDAL. Both sites use geoserver.

At anyrate the other issue I need to troubleshoot is for some reason GDAL wasn't picking up the new curl. I had originally compiled against curl - 7.67.0, but while GDAL recognized it kinda rejected it with not being able to find curl_global_init or some such thing so therefore did not include WFS/WMS any curl driver dependent etc support. So I had to revise to compile against curl 7.54.1 which is what I had used previously. So I'm checking to see whether it's an issue in my curl build or something about GDAL not handling newer curl.

But at anyrate — it seemed to load fine using the new curl (which is what is shipped with the PostGIS 3.0 bundle)

[robe]

okay I looked closer at the issue, and I think issue is my old curl didn't have a libz dependency and the new one does. The curl_global_init check fails because for some reason gdal can't find the libz file. trying to fix that now. At anyrate unless you are requiring new features of curl, I think the .dll I posted above should work fine as the newer curl is downward compatible with 7.54 one.

[robe]

On irc #gdal channel - just learned that 404000 is geoserver's way of saying 404. An inside geoserver joke evidentally.

related gdal IRC thread from ​http://irclogs.geoapt.com/gdal/%23gdal.2020-01-05.log

17:46:43	robe2:	Other issue I have is with ERROR: GDAL NotSupported [6] EPSG PCS/GCS code 404000 not found in EPSG support files. Is this a valid EPSG coordinate system?
17:47:09	robe2:	can't find that EPSG in pcs.csv but I could be blind but two geoserver wfs I have tried trigger the same issue
18:11:44	velix:	robe2: https://gis.stackexchange.com/tags/epsg-40400/info
18:11:45	sigq:	Title: epsg-40400 tag wiki - Geographic Information Systems Stack Exchange (at gis.stackexchange.com)
18:11:46	velix:	:))
18:11:50	velix:	I love jokes.
18:12:47	velix:	robe2: 404 is a pun on "CRS not found"
18:14:19	robe2:	grrh I hate jokes
18:14:47	robe2:	well not jokes that throw errors
18:28:36	velix:	robe2: cURL without gz? Wow, how are you getting -compressed stuff?
18:31:19	robe2:	I have no idea maybe I'm not
18:31:45	robe2:	but anyway I figured out my issue, I just can't use libz internal with GDAL anymore
18:31:50	robe2:	was using libz internal
18:32:12	robe2:	and I guess when I do that the curl can't find it's libz cause that's external
18:32:32	robe2:	So switched that the with-libz=/path/to/my/zlib-install
18:33:03	EvenR:	robe2: there's no more any pcs.csv file in GDAL 3. And 404000 has never been a valid EPSG CRS code
18:33:24	robe2:	EvenR yah that error I was mentioning was in GDAL 2.4.3
18:34:08	robe2:	I haven't retested on GDAL 3.0.2 -- was just testing the compile on 3.0.2 when I noticed my curl support wasn't being picked up either -- but that's all resolved now
18:34:51	robe2:	So if 404000 is a bogus CRS essentially meaning 404? why am I getting that error in GDAL 2.4.3 -shouldn't it just be ignored?
18:35:46	robe2:	EvenR I still haven't switched to shipping windows postgis builds with newer GDAL :( still fighting with EDB dependencies which strangely are okay now on my computer but not entirely okay on winnie
18:35:53	robe2:	So probably do that with PostGIS 3.1
18:36:24	robe2:	PostgreSQL windows EnterpriseDB = EDB
18:36:51	robe2:	stupid dance of making sure my shipped libs work with their shipped libs where there is cross over
18:37:23	EvenR:	"So if 404000 is a bogus CRS essentially meaning 404? why am I getting that error in GDAL 2.4.3 -shouldn't it just be ignored?". No idea how you got to the point where 404000 was queried, and what is is supposed to mean :-) Probably some custom CRS hickjacking a unusued EPSG code
18:38:48	robe2:	EvenR could be a windows only issue (or rather how Regina is compiling stuff) -- as I lifted the example from pramsey's WFS example - https://github.com/pramsey/pgsql-ogr-fdw
18:38:49	sigq:	Title: GitHub - pramsey/pgsql-ogr-fdw: PostgreSQL foreign data wrapper for OGR (at github.com)
18:39:10	EvenR:	that's not dependent on how you compiled GDAL, but how you use it
18:39:31	robe2:	and noticed I got the same bogus error when using massgis geoserver - WFS:https://giswebservices.massgis.state.ma.us/geoserver/wfs?service=WFS&version=1.0.0
18:40:18	robe2:	I know the mass gis one at least worked 2 years ago when I last tried - but both geoserver and gdal have changed -- sooo might be an issue or just my stupid compiling
18:40:24	robe2:	and env variables
18:41:17	robe2:	only thing I know is both massgis and geosolutions use geoserver and they are probably both using the latest version I would guess
18:41:22	EvenR:	https://giswebservices.massgis.state.ma.us/geoserver/wfs?SERVICE=WFS&version=1.0.0&REQUEST=GetCapabilities reports a <SRS>EPSG:404000</SRS> for a layer massgis:MAD.MAD_MASTER_ADDRESS_CHANGES. That EPSG code is not a real EPSG code. No idea what that was supposed to mean
18:41:23	sigq:	Title: Massachusetts Data from MassGIS (GeoServer)1 Minute Lat Long Grid10 Minute Lat Long Grid (at giswebservices.massgis.state.ma.us)
18:41:29	robe2:	as they are both big geoserver supporters
18:41:47	EvenR:	I'd guess a custom definition of a CRS. But that can't be interoperable
18:42:06	EvenR:	complain to the server administator ;-)
18:42:18	robe2:	Well I'd be complaining to both of them
18:42:21	robe2:	https://gis.stackexchange.com/tags/epsg-40400/info
18:42:22	sigq:	Title: epsg-40400 tag wiki - Geographic Information Systems Stack Exchange (at gis.stackexchange.com)
18:42:36	robe2:	velix link above about it being a joke :)
18:42:48	robe2:	a geoserver inside joke evidentally
18:43:29	robe2:	EvenR pramsey's example - https://demo.geo-solutions.it/geoserver/wfs
18:43:38	robe2:	gives me same troubles
18:44:34	EvenR:	ah ok, didn't know that geoserver used that hack. I'll try to silence that down in the WFS driver

[robe]

okay I've updated ​https://winnie.postgis.net/download/windows/pg12/buildbot/extras/gdal_2.4.3-with-curl.zip with gdal 2.4.3 compiled against curl - 7.67.0 with libz support.

Also repackaging the ogr_fdw 1.0.9 for all releases. Pg12 one is already done and is here - ​https://winnie.postgis.net/download/windows/pg12/buildbot/extras/ogrfdw-pg12-binaries-1.0.9w64gcc81.zip , but just replacing the libgdal-20.dll should be sufficient to fix your issue.

I'm going to wait off on building a new PostGIS bundle installer until one of the following happens

1) GDAL is changed upstream — as EvenR alluded to on #gdal irc

18:44:34	EvenR:	ah ok, didn't know that geoserver used that hack. I'll try to silence that down in the WFS driver

2) We release PostGIS 3.0.1 which I hope happens soon like in next 2 weeks — which might happen since we have a lot of semi-critical fixes ready to go or in route

or 3) Another PostgreSQL micro release comes out

[davis]

Replacing libgdal-20.dll works.

[robe]

Great. EvenR just released a 2.4.4RC1 with the fix for geoserver issue among other things. I'm planning to test that out and release when 2.4.4 officially comes out. It would be nice if we have a PostGIS 3.0.1 too, but I fear that may take a couple more weeks. So I'll go ahead and repackage a 3.0.0 as soon as ​https://github.com/OSGeo/gdal/tags (2.4.4 GDAL is released)

[robe]

I'm going to close this as I have the 3.0.1 branch building with 2.4.4 and curl support now. So at very least will be available in 3.0.1. I'll do a test before release.