Bug report #14254
FileGDB (ESRI FileGDB) from newer ArcGIS-Versions couldn't be opened
|Affected QGIS version:||2.12.2||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||not reproducable|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||22250|
Accessing a FileGDB (via ESRI-FileGDB driver) seems to be broken with a FileGDB created by newer ArcGIS-versions (10.3+).
FileGDBs createdare usable.
Maybe this issue is caused by ESRI due to a version-upgrade of FileGDB-API-dll from 1.3 to 1.4?
The included .dll in OSGeo4W-Installation is version 1.3.
#3 Updated by Benjamin Schepers over 5 years ago
- File DEMO.zip added
ERROR messsage was: "... infrastructure_1.gdb is not a valid or recognized data source."
Due to our ArcGIS-Update from 10.1 to 10.3, I concluded, that this was the reason for above error, moreover the file was readable in a crosscheck by self compiled GDAL/OGR on Linux with FileGDB-DLL 1.4 - this was misleading me!
I found the error by myself (two nearly identic GDBs attached, only difference is the layers "buildings" CRS ):
Version1 has a "custom" Authority/CRS in ESRIs point of view - the CRS-Parameters are definitely OK, but CRS-Authority/-ID is not explicitely declared as EPSG/WKID:25832
In Version2 I reassigned the CRS with ArcCatalog to EPSG/WKID:25832 and it worked well with QGIS.
So should we close this bug and open a new one to "implement" a more specific / not misleading error-message, ie. that there was an unknown CRS?
What about generally updating FileGDB-API to ist newest version 1.4?
Sorry for the confusion :-D