Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setSubsetOfAttributes() doesn't work #16892

Closed
qgib opened this issue Jun 13, 2013 · 4 comments
Closed

setSubsetOfAttributes() doesn't work #16892

qgib opened this issue Jun 13, 2013 · 4 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Data Provider Related to specific vector, raster or mesh data providers
Milestone

Comments

@qgib
Copy link
Contributor

qgib commented Jun 13, 2013

Author Name: Alexander Bruy (@alexbruy)
Original Redmine Issue: 8051
Affected QGIS version: master
Redmine category:data_provider
Assignee: Martin Dobias


I try to get features within some rectangle, and want to get only some attributes without geometries. So I use next code:

request = QgsFeatureRequest()
request.setFilterRect(self.extent)
request.setFlags(QgsFeatureRequest.NoGeometry)
request.setSubsetOfAttributes([0, 3, 6])
f = QgsFeature()
fit = layer.getFeatures(request)
while fit.nextFeature(f):
  attrs = f.attributes()
  # process attributes
  ...

but in attrs valiable I always get all feature attributes.

Confirmed also by Nathan, see http://lists.osgeo.org/pipermail/qgis-developer/2013-May/026119.html


Child issue(s): #16676
Redmine child issue(s): 7781


@qgib
Copy link
Contributor Author

qgib commented Jun 13, 2013

Author Name: Nathan Woodrow (@NathanW2)


I suspect it's this

// TODO[MD]: just one resize of attributes
f.setFields( &L->mUpdatedFields );

In QgsVectorLayerFeatureIterator::nextFeature

@qgib
Copy link
Contributor Author

qgib commented Jul 8, 2013

Author Name: Jürgen Fischer (@jef-n)


Is this a bug or a feature?

Before each feature had a map of attribute values with the attributes field index and it's value. So you could identify each attribute no matter how the feature was retrieved. Now we have an array of attributes and the index of an attribute in that array corresponds to the field index. So by looking at the feature you still know which attribute belongs in which field. Difference is, that the feature doesn't know which attributes were actually retrieved or are just fillers to get the indices right. You can still safely assume that all requested attributes are there, with their original index. But not that only those are there.

I think the implied solution for the ticket would be to only have an attribute array with the requested attributes. That would mean that the indices of the feature attributes would change and in turn all code that implies that an retrieved attribute has the field index would need to be identified and adjusted...

@qgib
Copy link
Contributor Author

qgib commented Jul 8, 2013

Author Name: Jürgen Fischer (@jef-n)


  • status_id was changed from Open to Feedback

@qgib
Copy link
Contributor Author

qgib commented Jul 9, 2013

Author Name: Nathan Woodrow (@NathanW2)


This is intended behavior now. The feature field list should equal the layer field list and the index should match.


  • resolution was changed from to wontfix
  • status_id was changed from Feedback to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Data Provider Related to specific vector, raster or mesh data providers labels May 24, 2019
@qgib qgib added this to the Version 2.0.0 milestone May 24, 2019
@qgib qgib closed this as completed May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Data Provider Related to specific vector, raster or mesh data providers
Projects
None yet
Development

No branches or pull requests

1 participant