QGIS and GDB issue with state published data?

Question

QGIS version 2.0.1-Dufour

I am new to QGIS.

I'm working on a pet project and thus far I have been working with Shapefiles (which QGIS handles just fine). Yet, one of the states I'm pulling data from is utilizing directory GDB zipfile and it seems as if QGIS is confused on the data.

Now, I new to GDB and it's workings so this could be just me. Data source : https://www.nevadadot.com/About_NDOT/NDOT_Divisions/Engineering/Location/Documents/NV_ROADS_gdb.aspx

when looking at this data through QGIS, and filtering and selecting a known value as in SURFACE_TYPE, it is not resolving it correctly.

SURFACE_TYPE should have the following values:

1 - UNIMPROVED 2 - IMPROVED 3 - PAVED

I do not know if this is due to QGIS and it's tools or how the data is structured.

I have talked with the data owner and they are a state agency that is low on man power. I'd like to see if we can't help them make this data compatible or find out why QGIS is not reading the data correctly.

if Shapefiles are going to be a thing of the past and GDB is replacing it, I know the open source community has it's work cut out.

Answer 1

The data in question uses subtypes and coded value domains. Shapefiles do not natively expose the "human readable" fields when coded value domains are applied, but rather show only the code. So the person who prepares your shapefile will also need to prepare you a table of coded values as they translate to the human readable descriptions, and then you can join them in QGIS. Rather than asking institutions to adapt their data models to QGIS, I wonder if QGIS can be made to understand coded values--it appears to already be halfway there. Many institutions will not permit the use of open source applications within their network, which precludes their support/understanding/compatibility with programs such as QGIS.

Answer 2

The FileGDB driver of GDAL that QGIS uses only features the basic transforming of the geometry from FileGDB to formats that QGIS understands.

The data is origially spread over several tables (just as you would do in an MS Access database). What you are missing is the non-geometry table to replace the codes in the attribute table with the human readable values.

The driver depends on the FileGDB API that ESRI provides for free. This might not support extracting of the non-geometry tables.

Some effort is made to build a free FileGDB driver without any dependency on ESRI stuff. If you need the additional data, consider sponsoring the implementation of the driver, or create those non-spatial tables yourself and add them to your project.

That's some kind of "You get what you paid for", the other way round.

Some links for further reading:

http://www.gdal.org/ogr/drv_openfilegdb.html

https://github.com/rouault/dump_gdbtable/wiki/FGDB-Spec

http://erouault.blogspot.de/2013/10/filegdb-format-reverse-engineered.html

http://libjoe.blogspot.com/2014/02/python-wrapper-for-esri-file.html

As you see from the dates, the topic is rather fresh.