QGIS » QGIS Application

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

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.

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

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.

Quite convincing, tanks a lot!

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().

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.

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.

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.