6

I load the following CSV data into QGIS 3 (specs below) as a table with no geometry using default options.

"V1","time","V2"
-49,"2021-12-28T00:12:17.725753Z",13.5
-50,"2021-12-28T00:11:17.839767Z",14.5
-49,"2021-12-28T00:10:17.958035Z",14.2
-52,"2021-12-28T00:09:18.078015Z",14.2

I open a python terminal to access the layer with table = QgsProject.instance().mapLayersByName("table")[0]

When I call getFeatures() I see that there are, correctly, 4 features

>>> list(table.getFeatures())
[<qgis._core.QgsFeature object at 0x00000215D6518948>, <qgis._core.QgsFeature object at 0x00000215D65189D8>, 
<qgis._core.QgsFeature object at 0x00000215D6518A68>, <qgis._core.QgsFeature object at 0x00000215D6518AF8>]
>>>

But when I call getFeature() I can access indices 0 through 5, suggesting that there are 6 features. The attributes of the first two features are unusual.

>>> table.getFeature(0).attributes()
[NULL, 'time', NULL]
>>> table.getFeature(1).attributes()
[NULL, 'time', NULL]
>>> table.getFeature(2).attributes()
[-49, '2021-12-28T00:12:17.725753Z', 13.5]
>>> table.getFeature(5).attributes()
[-52, '2021-12-28T00:09:18.078015Z', 14.2]

My assumption was that these two functions accessed the same data. But this suggests they don't and now I'm confused. What's going on, and how do I program defensively around it?

QGIS version
3.8.3-Zanzibar
QGIS code revision
685d8b15d2
Compiled against Qt
5.11.2
Running against Qt
5.11.2
Compiled against GDAL/OGR
2.4.1
Running against GDAL/OGR
2.4.1
Compiled against GEOS
3.7.2-CAPI-1.11.0
Running against GEOS
3.8.0-CAPI-1.13.1 
PostgreSQL Client Version
10.8
SpatiaLite Version
4.3.0
QWT Version
6.1.3
QScintilla2 Version
2.10.8
Compiled against PROJ
5.2.0
Running against PROJ
Rel. 5.2.0, September 15th, 2018
OS Version
Windows 10 (10.0)
3
  • 1
    When you loaded the CSV file (using the GUI presumably?) did you handle the header line? What did the preview table show? What does type(table.getFeature(0)) say? Jan 2 at 10:52
  • 1
    @bugmenot123 - the header line was handled (i.e. "first line contains headers") so the attribute table looks as it should. Calling type(table.getFeature(0)) returns <class 'qgis._core.QgsFeature'> Jan 2 at 18:14
  • 1
    It needs to be reviewed the source code. There may be a bug. Calling type(table.getFeature(10000)) returns a QgsFeature, too. Jan 2 at 21:21
6

You assume that there is a feature for ids 0 and 1, but table.getFeature(0 or 1).attributes() tells us that it is not true.

The following code prints existing feature ids.

ids = [f.id() for f in table.getFeatures()] # list comprehension
print(ids)
# OUT: [2, 3, 4, 5]

Then, continue using ids to be sure you use an existing ids.

for i in ids:
    attributes = table.getFeature(i).attributes()
    print(attributes)

If the table has millions of rows, use of the list comprehension may not be reasonable. Instead, use generator comprehension. Generator comprehensions use circular brackets () whereas list comprehensions use square brackets []. Generators don’t allocate memory for the whole list and are memory efficient.

ids = (f.id() for f in table.getFeatures()) # generator comprehension

Update:

  • if n header/skipped line, then ids start from header + skipped + 1. That is weird.

For example:

  • if no header and no skipped line, then ids start from 1
  • if 1 header and no skipped line, then ids start from 2
  • if 1 header and 2 skipped line, then ids start from 4
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.