Opened 5 years ago
Closed 5 years ago
#4612 closed defect (fixed)
No WFS support for OGR FDW under Windows
Reported by: | davis | Owned by: | robe |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 3.0.1 |
Component: | build | Version: | 3.0.x |
Keywords: | wfs, ogr fdw windows | Cc: |
Description
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
Change History (12)
comment:1 by , 5 years ago
Component: | postgis → build/upgrade/install |
---|---|
Keywords: | windows added |
Owner: | changed from | to
comment:2 by , 5 years ago
Owner: | changed from | to
---|
comment:3 by , 5 years ago
comment:4 by , 5 years ago
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' );
comment:5 by , 5 years ago
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)"
comment:6 by , 5 years ago
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)
comment:7 by , 5 years ago
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.
comment:8 by , 5 years ago
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
comment:9 by , 5 years ago
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
comment:11 by , 5 years ago
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)
comment:12 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
davis can you let me know which version of PostgreSQL you are using?
Sounds like I might have accidentally left out the curl dependency.