[QGIS-Developer] Proposal: changing the behaviour of QgsFeatureRequest

Tue Apr 30 13:35:37 PDT 2019

Greetings,

Yes as far as the number of request and iterator the same number would be
created, there is no workaround for that.

I'll try to set up a prototype PR if I can get the time to make up
something.

Should I work only in the base featurerequest/iterator or do it in a
provider? I'm not too sure when the base one and the dedicated one are used
in QGIs.

And should I got for a dedicated iteration method or simply add a trigger
to be in line with current API standards.

Thanks,

Alexis Roy-Lizotte

Le mar. 30 avr. 2019 à 08:28, Matthias Kuhn <matthias at opengis.ch> a écrit :

> Sorry, I lost you here.
>
> I think for both proposals three QgsFeatureRequests will need to be
> created, requested and iterators generated.
>
> Can you paste a minimal code sample here that demonstrates the use of your
> proposed API?
>
> Thanks Matthias
>
> On 4/30/19 1:00 PM, Alexis R.L. wrote:
>
> Hi,
>
> Well I could rework iterators to use the provided Fids as the base list to
> iterate over, this would mean that instead of checking every feature for
> each evaluation ( from what I'm seeing each evaluation goes through every
> feature and check for either the id number or if the expression is true.)
>
> If we are doing 3 evaluation on 3 distinct symbols, this mean that every
> feature will be iterated over 3 times. Because each features are checked
> one by one for each of the 3 expression to evaluate.
>
> By using Fids as the base list and incrementing the index of it, each
> feature should be evaluated only once and no Fids check would be necessary.
> (Assuming a simple legend with a depth of one.)
>
> This would drasticly speed up things when many loops are required on a
> single feature.
>
> Alexis Roy-Lizotte
>
>
> Le mar. 30 avr. 2019 à 06:30, Matthias Kuhn <matthias at opengis.ch> a
> écrit :
>
>> 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> 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> a
>>> écrit :
>>>
>>>> On Sun, 28 Apr 2019 at 07:18, Alexis R.L. <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
>>>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>>
>>> _______________________________________________
>>> QGIS-Developer mailing listQGIS-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
>>> +41 (0)76 435 67 63 <+41764356763>
>>> [image: OPENGIS.ch Logo] <http://www.opengis.ch>
>>>
>> --
>> Matthias Kuhn
>> matthias at opengis.ch
>> +41 (0)76 435 67 63 <+41764356763>
>> [image: OPENGIS.ch Logo] <http://www.opengis.ch>
>>
> --
> Matthias Kuhn
> matthias at opengis.ch
> +41 (0)76 435 67 63 <+41764356763>
> [image: OPENGIS.ch Logo] <http://www.opengis.ch>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190430/9194b24a/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/9194b24a/attachment-0001.png>