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 <[email protected] > <mailto:[email protected]>> 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 >> <[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] <mailto:[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> > -- 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
