Bug report #8001

Split features with simple and multigeometry into separet layers in ESRI personal geodatabase

Added by Piotr Pociask over 6 years ago. Updated over 6 years ago.

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.

test.mdb (632 KB) Piotr Pociask, 2013-06-05 12:41 AM

screenshot1.png (10.8 KB) Piotr Pociask, 2013-06-05 12:41 AM

screenshot2.png (14.8 KB) Piotr Pociask, 2013-06-05 12:41 AM

Associated revisions

Revision c8ff3866
Added by Radim Blazek over 6 years ago

ogr virtual layers mix single and multi types in sublayers, fixed feature count, fixes #8001

History

#1 Updated by Giovanni Manghi over 6 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 over 6 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 over 6 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 over 6 years ago

  • Status changed from Feedback to Closed

#5 Updated by Radim Blazek over 6 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 over 6 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

[1] [[http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Feature_class_basics/003n00000005000000/]]

#7 Updated by Radim Blazek over 6 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 over 6 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 over 6 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?

Also available in: Atom PDF