Bug report #6451
Wrong number of records in table of attributes of 1_polygon in imported vectors with overlapping parts
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Radim Blazek | ||
| Category: | GRASS | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 15691 |
Description
Import in GRASS the sample (very simple) attached vector.
It has two partially overlapping polygons, so in GRASS you will get a 1_polygon and a 2_polygon.
The reported number of features is right (4), but using QGIS the table of attributes shows just 3 records (should be 4, as per the non topological vector model).
Of course if reexporting the vector to shapefile, the result will have 4 features and 4 records.
Associated revisions
GRASS feature id fix, tables selection id fix, fixes #6451
History
#1
Updated by Giovanni Manghi almost 12 years ago
- Priority changed from High to Normal
#2
Updated by Radim Blazek over 11 years ago
- Assignee set to Radim Blazek
I remember that we talked about it in Essen and it was like you described. I tried again now and I have got 4 records in the table but 1xA and 3xB instead of 2xA and 2xB. It seems that it changed with new vector iterators but it is still buggy.
#3
Updated by Radim Blazek over 11 years ago
- Status changed from Open to Closed
Fixed in changeset b532151c97121bf263e6055a36d99c646d391cae.
#4
Updated by Radim Blazek over 11 years ago
The problem was that QgsGrassFeatureIterator was using GRASS geometry id as QGIS feature id, but GRASS geometry may be connected with multiple database records through multiple categories. I have changed it to use
qgis_feature_id = grass_geometry_id * 1000000000 + grass_cat
There is potential problem with such ids however. It wont work if such features are used (exported to different format, processed by plugin) by an application which does not support longlong feature ids. I was considering to scan first all geometries to find maximum number of cats per feature to multiply only by necessary factor (and use cat index within geometry instead of cat), but that would slow down start up. That will be probably necessary if you find it to be a problem.
In theory, the geometries linked to the same attributes, i.e. with the same cat, could be represented as multi type (multipoint,multiline,multipolygon) but because there is no limit how may geometries may have the same cat, it could result in huge geometries which could not be effectively handled by QGIS. This could be also scanned at beginning however and used if possible (most cases).