Feature request #5094

QGIS Server Web Feature Service capabilities

Added by Michael Douchin almost 3 years ago. Updated almost 3 years ago.

Status:Closed Start Date:02/27/2012
Priority:Normal Due date:
Assigned to:Marco Hugentobler % Done:

0%

Category:Mapserver (QGIS Server)
Target version:Version 1.8.0
Platform: Resolution:
Platform version: Patch supplied:Yes
Status info: Tag:

Description

Adding the Web Feature Service capabilities Version 1.0.0 to QGIS Server.

The WFS service will then be able to answer the following requests :
  • GetCapabilities, which provides the WFS Service capabilities
  • DescribeFeatureType, which provides the XML features schema
  • GetFeature, which provides the features
The request GetFeature accepts parameters to filter features :
  • BBOX, a bounding box in the features SRS
  • FEATUREID, a feature id
  • FILTER, a filter in Filter Encoding 1.0

The request GetFeature provides the feature in an XML format, GML2.

The WFS service (GetCapapbilities and GetFeature) has been tested with QGIS. The GetFeature output formats have been tested with OpenLayers (GML2 and GeoJSON).

2 patches are proposed in this redmine issue :
  • one for the trunk and branch 1.8
  • one for the 1.7
Each patch
  • adds a public method to get QgsGeometry in GeoJSON format
  • adds WFS 1.0.0 service capabilities to QGIS Server
  • extends WFS 1.0.0 service capabilities with GeoJSON output format.

wfs-server.patch - For branch 1.8 and trunk : This patch adds a public method to get QgsGeometry in GeoJSON format. This pacth adds WFS 1.0.0 service capabilities to QGIS Server This pacth extends WFS 1.0.0 service capabilities with GeoJSON output format. (54.2 kB) Michael Douchin, 02/27/2012 08:58 am

wfs-server-1_7.patch - For branch 1.7 : This patch adds a public method to get QgsGeometry in GeoJSON format. This pacth adds WFS 1.0.0 service capabilities to QGIS Server This pacth extends WFS 1.0.0 service capabilities with GeoJSON output format. (54.8 kB) Michael Douchin, 02/27/2012 08:58 am

wfs-server.patch (56.1 kB) Michael Douchin, 03/01/2012 08:43 am

wfs-server-1_7.patch (56.9 kB) Michael Douchin, 03/01/2012 08:43 am

wfs-server-1_7-V3.patch (58.1 kB) Michael Douchin, 03/02/2012 08:11 am

wfs-server-V3.patch (57.4 kB) Michael Douchin, 03/02/2012 08:11 am

wfs-server-V4.patch (66.5 kB) Michael Douchin, 03/19/2012 04:52 am

History

Updated by Michael Douchin almost 3 years ago

René-Luc D'Hont (3liz) is the real author of these patches.

Updated by Marco Hugentobler almost 3 years ago

Wow, that's really cool!!!
Thank you, Michael and René. I'm going to give it a try in the next days and will comment back.

Updated by Paolo Cavallini almost 3 years ago

Great, thanks. How do you compare this to the alternative option of integrating TinyOWS, who also offers WFS-T and OGC compliance?

Updated by Michael Douchin almost 3 years ago

Paolo Cavallini wrote:

Great, thanks. How do you compare this to the alternative option of integrating TinyOWS, who also offers WFS-T and OGC compliance?

Hi Paolo,

In all the QGIS source code, we easily found all we need to implement WFS and WFS-T in QGIS Server ( WFS provider, Feature Encoding parser, feature editor, etc ). 2 days of work were enough to provide these patches.
René-Luc told me it won't be hard to implement WFS-T either.

TinyOWS only works with PostGIS and does not use QDOM. Having WFS capabilities in Qgis brings more supported vector formats.
And we think that 1 config file (here the Qgis) projectfor geo services is better than 2.

Doing this patch, we have seen some opportunities to better organize the code and refactor some things. We planned to participate to the next Qgis HF, which would be a great opportunity to coordinate the work.

Updated by Paolo Cavallini almost 3 years ago

Quite convincing, tanks a lot!

Updated by Marco Hugentobler almost 3 years ago

One thing that would be good for WFS is to stream the data for GetFeature (send it in pieces to avoid keeping the DOM in memory), because the data can be very large.

http://en.wikipedia.org/wiki/Chunked_transfer_encoding
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidoutputbuffersize

It seems mod_fcgid supports that per default. So it should be enough to set 'Transfer-Encoding: chunked' in the header of the GetFeature response and print the xml text to FCGI_stdout when stepping through nextFeature().

Updated by Michael Douchin almost 3 years ago

Hi Marco, all

René-Luc followed the proposition of Marco :
  • no Header Content-Length for GetFeature response
  • GetFeature is like a stream, chunked doesn't be used
  • Adding MAXFEATURES parameters

See new patches attached

Updated by Michael Douchin almost 3 years ago

Reluc just finished new versions of the patches wfs-server-1_7-V3 (for 1_7) and wfs-server-V3 (for 1_8) :

  • Adding support for PROPERTYNAME parameter: This one gives the ability to only retrieve the attributes we want, geometry included.

With theses patch, QGIS Server will implement all the OGC WFS standard version 1.0.0 in KVP, and the GetFeature Response is in a stream mode.

These patches replace the previous ones

Updated by Michael Douchin almost 3 years ago

The new patch attached (wfs-server-V4.patch) adds the capability to select the published layer in the WFS Service via the project properties dialog, and enhance the code to publish features in the GetFeature Request.
It is made for 1.8 version and replace the previous ones (no patch supplied for 1.7 this time)

Updated by Vincent Picavet almost 3 years ago

Hi,

TinyOWS only works with PostGIS and does not use QDOM. Having WFS capabilities in Qgis brings more supported vector formats. And we think that 1 config file (here the Qgis) projectfor geo services is better than 2.

TinyOWS supports various WFS versions. It provides CITE test compliance, therefore a strong compliance to OGC standards, and tries to support now WFS* standard versions as they come out.

What version(s) of WFS/WFS-T does your patch support ?

It is planned for TinyOWS to support other backends, namely spatialite, offering a way to support other (embedded) vector formats. I think it is not advisable to offer WFS-T with a non-transactional backend, because WFS-T IS transactional by nature.

Adding support for TinyOWS to read its configuration from a QGIS config file is trivial, as it's already done for Mapserver config files, which are harder to read than QGIS XML format.

Performance-wise, TinyOWS will be very hard to beat, due to its lightweight structure, and its proximity to the data.
As TinyOWS is a little piece of code, therefore easy to maintain, and it's easier to prove its security against various exploits like SQL injections.

Having a loose coupling adds a few interesting possibilities, like having TinyOWS working behind a apache/nginx http frontend, and maybe as a module in the future, without having to do the same for QGIS.

Having yet another WFS implementation is from my point of view a waste of time, and adds maintenance efforts to the project for the future, instead of adding collaboration and factorization of features among OSGeo projects. But hey, it's opensource.

Updated by René-Luc ReLuc almost 3 years ago

Hey it's opensource,

We, at 3Liz, would like to have WFS directly in QGIS Server like MapServer has, because we don't want to install QGIS Server and TinyOWS, and we would like to have multiple WFS services, one for each QGIS project, on one server.

We don't want to compete with TinyOWS performance, we just want to use QGIS and Qt capabilities server side.

Our first step is to implement KVP WFS 1.0.0 version. If we'll find time we go forward.

Updated by Vincent Picavet almost 3 years ago

We, at 3Liz, would like to have WFS directly in QGIS Server like MapServer has, because we don't want to install QGIS Server and TinyOWS,

TinyOWS is really tiny (!) and does not have any rare dependency, adding very little to your install. It's really easy to compile and is also available as debian package. Install does not seem to be a real problem. It could even be bundled with QGIS installer without any problem.

and we would like to have multiple WFS services, one for each QGIS project, on one server.
You can do that already with TinyOWS, with different config files, one for each project.

As for Mapserver, there is a good chance that they drop internal WFS support once TinyOWS is able to deal with a few more backends. Less code = less bug = less maintenance.

We don't want to compete with TinyOWS performance, we just want to use QGIS and Qt capabilities server side.

I don't get the QT capabilities part ?
Having good performances for WFS-T is important, as it's a demanding service as soon as you have more than just a few users. That's also where a transactional backend is mandatory.

Updated by Marco Hugentobler almost 3 years ago

  • Status changed from Open to Closed

Added to master branch in commit c27c89045c172ae1afc68a5571552e145d426f15. Thank you René-Luc for this nice work!

To WFS with TinyOWS <-> WFS with QGIS server:
There are pros and cons for both. I'm appreciating TinyOWS very much. It is an efficient piece of software and written in a clean coding style. I can however also see the benefits
of including WFS support directly into QGIS server (automatically support all the QGIS datasources, support attribute aliases, considering hidden attributes).
So now the user can choose the approach best suited for a particular task.

Also available in: Atom PDF