Bug report #8001
Split features with simple and multigeometry into separet layers in ESRI personal geodatabase
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: |  Radim Blazek | ||
| Category: | Data Provider | ||
| 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 #: | 16851 |
Description
After af0f61e6 when I'm trying to open layer from ESRI Personal Geodatabase in Select vector layers to add... dialog features from that layer are split into two sublayers (see screenshots) - multipolygons and simple polygons.
Also when there is a more than one layer Number of features in dialog is repeating numbers from first layer in all layers (screenshot #2)
383e7f1 doesn't change this behavior.
I've attached sample PGeo file.
Associated revisions
ogr virtual layers mix single and multi types in sublayers, fixed feature count, fixes #8001
History
#1
Updated by Giovanni Manghi almost 11 years ago
- Status changed from Open to Feedback
it this a regression since 1.8 and/or a previous master release?
#2
Updated by Piotr Pociask almost 11 years ago
It's occurs in version 1.9.0-295 (24bffbf2) and it's probably related with af0f61e699d89c4db9ee8f618c032b75e6211d33.
QGIS 1.8 (from OSGeo4W) is not affected.
#3
Updated by Giovanni Manghi almost 11 years ago
- Crashes QGIS or corrupts data changed from Yes to No
- Priority changed from Normal to Severe/Regression
then is a regression.
#4
Updated by Radim Blazek almost 11 years ago
- Status changed from Feedback to Closed
Fixed in changeset c8ff3866957ea0851c515e17c018c1271f687da1.
#5
Updated by Radim Blazek almost 11 years ago
Single/multi types were represented as separate sublayers because that is how usual formats work (shapefile, Postgis,...) and some operations like drag/drop and copy/paste may fail if there are geometry type constrains. I have changed it so that now single/multi and 2D/25D are all mixed in single sublayer.
Wrong feature count was simply bug.
It should be fixed, if not, please attach also an mdb with multiple layers and multiple geometry types.
I am worried a bit about possible performance problems with mdb, because if geometry type is unknown, which is the case in your example, OGR provider scans all features to get list of available geometry types. Is it usual that there are mixed geometry types in a single table? Does mdb has something like geometry_columns where geometry types are defined?
#6
Updated by Piotr Pociask almost 11 years ago
Thanks Radim for quick fix. I've tested QGSI master and for now mdb files are working ok.
About performance issues when I'm opening mdb with 4 layers with total 25K features I don't feal any slowdown. Only when I'm opening this file from server it takes over 10 sec. to popup layer selection dialog - but this is very similar as it was before changes.
I've review mdb structure and there is GDB_GeomColumns table with ShapeType column. But it's seems that there are only 4 types for vector: point, multipoint, line and polygon, where line and polygon can also contain multipart geometries (see [1]). So I think this is usual to have mixed types in single table - anyway it's in my organization.
Regards
Piotr
#7
Updated by Radim Blazek almost 11 years ago
Piotr Pociask wrote:
About performance issues when I'm opening mdb with 4 layers with total 25K features I don't feal any slowdown. Only when I'm opening this file from server it takes over 10 sec. to popup layer selection dialog - but this is very similar as it was before changes.
If it is only slow with network files on Windows, it could be similar problem as #6448.
I've review mdb structure and there is GDB_GeomColumns table with ShapeType column. But it's seems that there are only 4 types for vector: point, multipoint, line and polygon, where line and polygon can also contain multipart geometries (see [1]). So I think this is usual to have mixed types in single table - anyway it's in my organization.
If geometry types are known for tables, there should be no slowdown, features are scanned only if geometry type is unknown.
#8
Updated by Piotr Pociask almost 11 years ago
Radim Blazek wrote:
If it is only slow with network files on Windows, it could be similar problem as #6448.
Maybe this is related, I will try do more tests in next week.
If geometry types are known for tables, there should be no slowdown, features are scanned only if geometry type is unknown.
ogrinfo is showing Unknown (any) geometry type for all layers that I check.
#9
Updated by Radim Blazek almost 11 years ago
Piotr Pociask wrote:
If geometry types are known for tables, there should be no slowdown, features are scanned only if geometry type is unknown.
ogrinfo is showing Unknown (any) geometry type for all layers that I check.
Strange, for the test.mdb I have got
1: tmpLayer (3D Polygon)
on Linux with OGR 1.9.2 MDB driver based on Jackcess library.
That explains however why it was giving polygon + multipolygon sublayers before the fix.
Which types are defined in your GDB_GeomColumns?