Tell me more ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.
up vote 3 down vote favorite
1

I am running QGIS 1.8. I have a layer from an ESRI Personal GDB. There are 431 features in the layer. When you load the layer into QGIS, and look at the Metadata properties, it shows the number of features as 431. layer metadata

When I open the attribute table, the table only shows 180 features. Layer attribute table

This is a layer that had been loaded in straight from the Personal GDB. No filters or queries had been added to it, so all features should be showing.

I first came across this issue because another coworker was trying to access the same layer using QGIS 1.7. He was having the same issue.

A couple items of note:

  1. This layer was existing in the PGDB, and then using ArcGIS, I copied and replaced a new version from a File GDB into the PGDB.
  2. I am able to load other layers from the same PGDB into QGIS where all the features are displayed.
  3. The PGDB is a modified MS Access database. If you open the database with MS Access, then open the table for this layer, it contains all 431 records with attributes.

Here is a screenshot of the layer in QGIS: QGIS Screenshot

Here is a screenshot of the same layer in ArcGIS: ArcMap Screenshot

If anyone has some insight into why QGIS is able to see the actual number of features in the layer, but is only displaying a certain number, I would appreciate it.

share|improve this question
1  
My guess would be that the count is stored in the file header (also for r/w offsets) and is not actually constructed by counting each time. No idea what went wrong though. – lynxlynxlynx Sep 15 '12 at 9:23
@lynxlynxlynx - I edited the post to say that if you open the PGDB with MS Access, the table for this layer contains all 431 records and attributes. – Get Spatial Sep 15 '12 at 10:15
2  
In MS Access, how does the 181st record look? Could it have some untrapped error or special character? – andytilia Sep 15 '12 at 11:00
@andytilia - It looks like we have a winner. The coordinates for 181 seem to be nonexistent. Looking through the rest of the table, there are a few others as well. If you were to post that as an answer, I'd be happy to give you credit for it. – Get Spatial Sep 17 '12 at 16:34
@GetSpatial, thanks ;-) – andytilia Sep 17 '12 at 17:44

2 Answers

up vote 2 down vote accepted

Open the Personal GDB in MS Access to make sure the records not shown in QGIS all have valid data, including coordinates. I'd first check the 181st record (in your case), being the first record not shown in QGIS.

Given your confirmation in the comment above, you might file a bug with the QGIS team to request a visible error message in case invalid data is found.

share|improve this answer
1  
Hm. I think it's a bug. Or is it a feature request? – andytilia Sep 17 '12 at 17:45
up vote 1 down vote

Probably one of the feature's geometries is failing to hydrate. Can you print all of the geometries with ogrinfo -al datasource

share|improve this answer
Not sure what you mean by failing to hydrate. Upon further investigation, a number of the features have no spatial data. It seems that the record was added to the attribute table, with no spatial data being encoded in the shape field. Interesting that the same layer, with the same features in a File GDB, loads all 431 features, and simply does not display those missing spatial data, where the Personal GDB stops loading at the first feature with an error. – Get Spatial Sep 17 '12 at 22:59
To answer your question directly, running ogrinfo -al datasource only loads the first 180 records. That is, it loads the records until it hits the first record with an error in the spatial data. Running ogrinfo datasource layer -where "OBJECTID=183", which is the next valid point, correctly lists the data for that record. This indicates that it is able to read the subsequent, valid, records, but not all of them in a row. – Get Spatial Sep 17 '12 at 23:14
so basically the qgis reader is stopping at the first error instead of just skipping the errors (similar to the --skipfailures ogr2ogr flag. It looks like an enhancement request / bug fix. – Ragi Yaser Burhum Sep 18 '12 at 0:09
1  
Created Bug report: hub.qgis.org/issues/6368 – Get Spatial Sep 18 '12 at 22:54
cool. This is the only way that open source products get better - when users submit good bug reports. +1 – Ragi Yaser Burhum Sep 20 '12 at 17:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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