[Qgis-developer] Better getNextFeature in vector providers

[Brendan Morley]

Martin,

I had thought 0.8 is already in feature freeze; though my interpretation
of that was "get WMS finished, not just started" (-:  Therefore I vote
you do this in some post-0.8 branch.

Can I also suggest that as a result of me looking at what's required of
a WFS implementation, I've realised that getNextFeature will soon have
to deal with nested attributes (this is because the XML Schema
specification allows it).  When reimplementing getNextFeature, please
make sure it can be easily "scaled" to nested attributes in future.

Finally Mateusz, QVariant can have user variants - therefore I'm not
sure if the refactoring of getNextFeature is a good enough reason to
drag in the "boost" dependency.


Brendan


On Fri, 2006-03-17 at 16:23 +0100, Martin Dobias wrote:
> Hi,
> 
> currently I'm playing again with searching and filtering features from
> vector layers. Now, QgsVectorDataProvider has several access methods
> for features:
> - QgsFeature* getFirstFeature(bool fetchAttributes)
> - QgsFeature* getNextFeature(bool fetchAttributes)
> - QgsFeature* getNextFeature(std::list<int> const & attlist, int
> featureQueueSize)
> - bool getNextFeature(QgsFeature &feature, bool fetchAttributes)
> 
> Notes:
> - getFirstFeature is redundant and nearly not used at all
> - last getNextFeature call is probably the best since it doesn't
> create QgsFeature every time, but it misses implementation in
> PostrgreSQL, GRASS and GPX providers, so far not used at all in QGIS
> - getNextFeature with list as a parameter specifies attributes we're
> interested in
> 
> In my opinion it's not very practical and in case I need to access
> only attributes I always get also geometry. Therefore I'd like to
> suggest improving this interface for more flexible access. This is my
> idea of how this should work:
> 
> Only one accessor: bool getNextFeature(QgsFeature& feature)
> Feature that will be passed to getNextFeature could set:
> - hasGeometry(bool)  -- default true
> - hasAttributes(bool) -- default false
> Accessor function will consider these flags and won't do actions which
> are not required.
> 
> Also dealing with feature attributes should be improved - I've started
> some work on this to at least make difference between string and
> numeric values. This is not very good solution though. My opinion is
> to use QVariant classes for values (or something similar).
> 
> 
> Now question mainly on Gary: what is the current plan of 0.8 release?
> Should we wait with more improvements until it's released? (I'd like
> to implement filtering of vector layers to work with providers other
> than PostgreSQL) Or what about creating 0.8 release branch for
> bugfixes while development can go on in trunk?
> 
> Bye,
> Martin
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qgis-developer
>