QEP 53: WFS provider enhancements about qgis-enhancement-proposals HOT 10 OPEN

Hi @rouault,

I don't have a lot of experience with WFS, but it's great to see the undermaintained WFS provider getting some attention. A couple of small comments regarding this:

• Consider implementing a python provider test which inherits from ProviderTestCase (see eg tests/src/python/test_provider_mssql.py). This will help identify any issues in the provider where handling of different requests differs from the other vector providers
• I'd also strongly suggest implementing handling of QgsFeatureRequest::FilterFids in QgsWFSFeatureIterator. This will give a HUGE performance boost across lots of areas when using WFS layers.
• Similarly, I'd suggest implementing an expression compiler for QgsExpression -> WFS filters, so that QGIS expression based filters can be handled on the server side (rather then fetching all features and testing them in QGIS). Have a look at QgsSqlExpressionCompiler, and the implementations in QgsOgrExpressionCompiler, QgsSpatiaLiteExpressionCompiler etc. This will also give a huge performance boost to the provider.

from qgis-enhancement-proposals.

@nyalldawson

Consider implementing a python provider test which inherits from ProviderTestCase (see eg tests/src/python/test_provider_mssql.py). This will help identify any issues in the provider where handling of different requests differs from the other vector providers

Thanks for the pointer. Looking at the runGetFeatureTests() method, due to the large number of tests, it might require a real WFS server especially, which might be impractical. I'd thought rather to have a dummy server returning a few prepared responses. Or perhaps have a dual strategy: rather extensive tests requiring to setup a real WFS server (that would be optionally run), and more simple ones that could be run without requiring a WFS server.

I'd also strongly suggest implementing handling of QgsFeatureRequest::FilterFids in QgsWFSFeatureIterator. This will give a HUGE performance boost across lots of areas when using WFS layers.

Which actions can trigger such type of filter ? This should be implementable through a FeatureId (1.0) /GmlObjectId (1.1) /ResourceId (2.0) filter

Similarly, I'd suggest implementing an expression compiler for QgsExpression -> WFS filters

There's already one implemented in QgsOgcUtils::expressionToOgcFilter() (will require work to support new WFS versions) used currently at layer creation when the user defines the layer. I guess this will have to be used again for filters defined afterwards and combined with the initial filter. But not all QGIS expressions can be turned into valid WFS server filters, so client-side fallback will be sometimes needed.

from qgis-enhancement-proposals.

Who is the main owner of the WFS code?

On Wed, Jan 27, 2016 at 8:38 AM, Even Rouault [email protected]
wrote:

@nyalldawson https://github.com/nyalldawson

Consider implementing a python provider test which inherits from
ProviderTestCase (see eg tests/src/python/test_provider_mssql.py). This
will help identify any issues in the provider where handling of different
requests differs from the other vector providers

Thanks for the pointer. Looking at the runGetFeatureTests() method, due to
the large number of tests, it might require a real WFS server especially,
which might be impractical. I'd thought rather to have a dummy server
returning a few prepared responses. Or perhaps have a dual strategy: rather
extensive tests requiring to setup a real WFS server (that would be
optionally run), and more simple ones that could be run without requiring a
WFS server.

I'd also strongly suggest implementing handling of
QgsFeatureRequest::FilterFids in QgsWFSFeatureIterator. This will give a
HUGE performance boost across lots of areas when using WFS layers.

Which actions can trigger such type of filter ? This should be
implementable through a FeatureId (1.0) /GmlObjectId (1.1) /ResourceId
(2.0) filter

Similarly, I'd suggest implementing an expression compiler for
QgsExpression -> WFS filters

There's already one implemented in QgsOgcUtils::expressionToOgcFilter()
(will require work to support new WFS versions) used currently at layer
creation when the user defines the layer. I guess this will have to be used
again for filters defined afterwards and combined with the initial filter.
But not all QGIS expressions can be turned into valid WFS server filters,
so client-side fallback will be sometimes needed.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

from qgis-enhancement-proposals.

I'd also strongly suggest implementing handling of QgsFeatureRequest::FilterFids in QgsWFSFeatureIterator. This will give a HUGE performance boost across lots of areas when using WFS layers.
Which actions can trigger such type of filter ? This should be implementable through a FeatureId (1.0) /GmlObjectId (1.1) /ResourceId (2.0) filter

Lots - mostly related to operations on a set of selected features. Eg, zooming to selected features, saving selected features, processing operations which work on selected features.

from qgis-enhancement-proposals.

Lots - mostly related to operations on a set of selected features. Eg, zooming to selected features, saving selected features, processing operations which work on selected features.

OK, so I think that in practice if the features are already selected, they will be already locally cached, and no extra server query will be needed.

from qgis-enhancement-proposals.

There's already one implemented in QgsOgcUtils::expressionToOgcFilter() (will require work to support new WFS versions) used currently at layer creation when the user defines the layer. I guess this will have to be used again for filters defined afterwards and combined with the initial filter. But not all QGIS expressions can be turned into valid WFS server filters, so client-side fallback will be sometimes needed.

That's exactly how the existing expression feature request filters work - they hand off as much work as possible to the server, and then implement any further checks as a fallback to match the behaviour of QGIS expressions. Eg, spatialite provider can't hand off case sensitive matches, so it performs a case -insensitive match server side and then performs an extra filter on the qgis side to strip out non case-matching results. It still results in much less features sent from the provider -> QGIS to handle.

from qgis-enhancement-proposals.

Oops - pressed the wrong button :)

from qgis-enhancement-proposals.

+1 This looks really good to me. Thanks to LINZ for funding the work!

from qgis-enhancement-proposals.

@rouault will this document change much. If not I will apply the Final Draft tag.

from qgis-enhancement-proposals.

@NathanW2 There will be likely some adjustments

from qgis-enhancement-proposals.