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 <[email protected] > <mailto:[email protected]>> a écrit : > > On Sun, 28 Apr 2019 at 07:18, Alexis R.L. <[email protected] > <mailto:[email protected]>> 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 > > [email protected] > <mailto:[email protected]> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Matthias Kuhn [email protected] <mailto:[email protected]> +41 (0)76 435 67 63 <tel:+41764356763> OPENGIS.ch Logo <http://www.opengis.ch>
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
