[Qgis-developer] Better getNextFeature in vector providers

[Martin Dobias]

On 3/18/06, Brendan Morley <morb at beagle.com.au> wrote:
> 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.

Hi Brendan,

Gary has recently set feature freeze to March 31, he confirmed to me
on IRC that it's ok to do some more improvements until that date.
Personally I don't think these changes are very big and I can surely
finish it on time.


> 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.

I would say that nested attributes can be flattened easily: they can
get field indexes in the order as they appear in schema and their
names can reflect nesting, e.g. "level1:level2:level3" could be name
for an attribute nested two levels deep. Does this make sense to you?


> 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.

I guess that Mateusz meant that only one header from boost would be
needed, not the whole library. However after some thinking and looking
in QVariant sources, I don't think that we really need something like
boost::any and that QVariant will suffice - I didn't find any
inefficiencies in the implementation. The second reason is that we
should prefer Qt classes to make the code as consistent as possible.

--------

Is this OK for everyone? Everything is in one call, allows to fetch
geometry or not, allows to specify what attributes to fetch
(identified by attribute index).

bool getNextFeature(QgsFeature& feature, bool fetchGeometry = true,
   std::list<int>& fetchAttributes = emptyList)

(emptyList will be static member of QgsVectorDataProvider, providing
default argument for the function)


Martin


>
>
> 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
> >
>
>