[QGIS-Developer] Proposal: changing the behaviour of QgsFeatureRequest
Matthias Kuhn
matthias at opengis.ch
Tue Apr 30 03:30:48 PDT 2019
Hi,
An expression `attribute = 'major_road' AND $id IN (1,2,3)` should have
the same result on the number of features in the iterator. Or I am
missing something.
Matthias
On 4/30/19 12:13 PM, Alexis R.L. wrote:
> Greetings Mr.Kuhn,
>
> Well in my case the fact that each symbol node is evaluated add some
> lenght to the computation, if I can make something that would only
> iterate over a given list of Fids, (and at the same time prevent
> having to iterate over each feature to check if that feature is within
> the given list of feature) we would move from something that takes x
> by n loops to something that would only take around x loop ( where x
> is the number of features and n is the number of symbol).
>
> For other use case the gain might be minimal. Other similar behaviour
> could be used with selected features (though I'm not sure if this is a
> perfect match for this also.)
>
> This gain in efficiency is why I want to alter the iterator itself
> rather than fiddling with expressions, despite the fact that this is
> also a possibility but far less optimal for the reason mentioned above.
>
> I just want to know what would be the best way to alter the iteration
> process without breaking and in a way that could be leveraged.
>
> Thanks.
>
> Alexis Roy-Lizotte
>
>
> Le mar. 30 avr. 2019 à 02:31, Matthias Kuhn <matthias at opengis.ch
> <mailto:matthias at opengis.ch>> a écrit :
>
> Hi,
>
> I like the idea of a nicer API to combine several filter
> conditions. Currently the only possibility to perform this
> operation is to write a filter expression as a string or by
> combining expression nodes.
>
> I am not convinced however that this should be done directly on
> QgsFilterRequest level. It feels a bit like reimplementing the
> expression engine on another level again.
>
> Some questions that come to my mind:
>
> * Are these filters always combined with AND or also OR?
>
> * Can these filters eventually be nested?
>
> * How should we deal with compiling expressions, should that be
> implemented again?
>
> An alternative approach would be to work on a nicer API for an
> expression builder to require 1) less string manipulation when
> building an expression and 2) have more introspection capabilities
> when manipulating an expression.
>
> Regards
>
> Matthias
>
> On 4/29/19 9:02 PM, Alexis R.L. wrote:
>> Greetings Mr. Dawson,
>>
>> Thanks for the reply,
>>
>> The tests that I did with the method in my PR was provider
>> agnostic but still entailed looping over every feature to do the
>> check. Could you provide idea or methods that could enable this
>> behaviour in an API friendly way?
>>
>> Should I make a new iterator entirely or should I modify existing
>> methods and add a trigger like I tested in my PR?
>>
>> Thanks!
>> Alexis Roy-Lizotte
>>
>>
>> Le dim. 28 avr. 2019 à 19:46, Nyall Dawson
>> <nyall.dawson at gmail.com <mailto:nyall.dawson at gmail.com>> a écrit :
>>
>> On Sun, 28 Apr 2019 at 07:18, Alexis R.L.
>> <alroyliz0 at gmail.com <mailto:alroyliz0 at gmail.com>> wrote:
>> >
>> > Greetings Everyone,
>> >
>> > While working on my PR (9648) I noticed that expression
>> filter and a list of feature IDs are both considered the same
>> thing cannot be used as two filtering criteria.
>> >
>> > I am aware that the intent was to only have one element
>> active to filter out features other than the rectangle(?
>> might be wrong on that one).
>> >
>> > What I am wondering if it would be a good thing to have
>> both co exist (mostly for my PR as of now). A simply way to
>> do so would be to use the give feature ids as the list to
>> iterate over and check for the expression if there is one.
>>
>> I also think this would be desirable. The tricky part (well, one
>> tricky part -- feature iterators are low level stuff, lots of
>> complexity there!) is avoiding any API breakage while adding new
>> methods to handle your use case.
>>
>> The other (SUPER) tricky bit is that any change to feature
>> requests
>> usually requires accompanying changes to every vector data
>> provider in
>> order to keep consistent behaviour across all these
>> providers. The
>> same request should always give the same result, regardless
>> of the
>> actual underlying data provider. The consequence of this is that
>> you'll need to be update the postgres, mssql, oracle, OGR,
>> memory,
>> spatialite, wfs, arcgis feature server, db2, and vector layer
>> feature
>> iterator code. You'll also need to add many new unit tests to
>> cover
>> all the changes to the different providers.
>>
>> Definitely not a trivial change! Don't let this put you off
>> making it,
>> but just be aware that this change would take even a QGIS core
>> developer a week or more of work to implement.
>>
>> Nyall
>>
>>
>>
>> >
>> > I assume that such a thing might be implemented without
>> touching the current behaviour, otherwise one would have to
>> remove either the expression or the IDs in some case when we
>> want to override the current filtering method.
>> >
>> > Using multiple filtering method might be better than only
>> forcing one and would provide more flexibility.
>> >
>> > As I have a PR that is related to this
>> (https://github.com/qgis/QGIS/pull/9816 ) I would like to
>> address this point in it and would like to have the
>> discussion occur there as to the best way to implement such a
>> thing without any breakage if people are not opposed to
>> having only one filtering method in qgsfeaturerequest.
>> >
>> > Thanks and have a nice day!
>> >
>> > Alex
>> > _______________________________________________
>> > QGIS-Developer mailing list
>> > QGIS-Developer at lists.osgeo.org
>> <mailto:QGIS-Developer at lists.osgeo.org>
>> > List info:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> --
> Matthias Kuhn
> matthias at opengis.ch <mailto:matthias at opengis.ch>
> +41 (0)76 435 67 63 <tel:+41764356763>
> OPENGIS.ch Logo <http://www.opengis.ch>
>
--
Matthias Kuhn
matthias at opengis.ch <mailto:matthias at opengis.ch>
+41 (0)76 435 67 63 <tel:+41764356763>
OPENGIS.ch Logo <http://www.opengis.ch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190430/23c835b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6671 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190430/23c835b1/attachment-0001.png>
More information about the QGIS-Developer
mailing list