I tried to export a simple shapefile with polygons via "save as" > Format "ESRI fileGDB" and choose "DHDN / Gauss-Kruger zone 3". So there is the error message : "Error: Failed at creating table for \project (General function failure.)"

With choosing the projection "WGS84" it works proper, but the data are needed in "DHDN / Gauss-Kruger zone 3". Any suggestions about that? Or solutions?


1 Answer 1


I assuming you are using QGIS and that error is what you are getting when it is using GDAL's FileGDB API internally. How do I know this? I made a mistake and forgot to remove the \ from the table name when in the root :)

To answer your question, sadly, there are several EPSG projections that are not properly handled by ESRI's Open FileGDB API.

In order to create the API separate from the rest of the ESRI stack, ESRI took out the projection engine that is used by the rest of ArcGIS. Instead, they implemented a simple version of it. Sadly, sometimes the outputs values that may not be compatible with the rest of ArcGIS. In fact, I have some FeatureClasses that were exported with the FileGDB API which open fine in ArcGIS Explorer (which also uses the FileGDB API), but will refuse to open in ArcCatalog.

There are some options in ogr2ogr that would allow to force a specific SpatialReference (as specified by the command line), but those options are not completely honored by the GDAL FileGDB driver just yet. In theory, that would allow you to circumvent this issue.

The only thing I can recommend to work around this issue is to edit GDAL's database of projections (those CSVs in the GDAL_DATA folder) for that particular spatial reference to match the string that the ESRI stack wants. Not for the faint of heart and definitely not 100% guaranteed that it will work.

Until somebody decides to extend the voodoo in the morphToESRI method from GDAL to handle this specific case, it will not work. If you really want this handled I would try submitting a request in the GDAL Bug tracker. If we get enough of these requests one of us will break down and tackle this lingering zombie issue.

Sorry about that.

Update 1:

Yeah, that did not work. You are going to need to export using a different projection or even a Null projection.

The ideal solution would be for ESRI to extend the FileGDB API so you could create one of their projections objects by only specifying an EPSG SRID, then I wouldn't have to resort to the Voodoo and just point to an "official" SRID. That way we would have two ways of supporting projections and one would be a sane interoperable way.

  • Thanks for your reply, advice and explanation! You mean I should replace the settings (e.g. PARAMETER_VALUE_4,...) for COORD_REF_SYS_NAME="WGS 84 / World Equidistant Cylindrical" in the pcs.csv (C:\OSGeo4W\share\gdal) with the settings of COORD_REF_SYS_NAME="DHDN / 3-degree Gauss zone 3"? It´s terribly clear that "open" APIs in ESRIs universe have a different meaning than in our... Regards.
    – user10840
    Oct 9, 2012 at 17:42
  • yeah. Basically, I would try to export a shapefile using ESRI software and look at the prj file. Then look at the string from the file you mentioned. change it to match the ESRI one. It is definitely worth a shot, but it may not work, so cross your fingers in the meantime. Oct 9, 2012 at 18:18
  • @Ragi sadly it is not working as you suggested. So far ArcCatalog is needed to change the projection of fileGDBs after exporting data from QGIS.
    – user10858
    Oct 10, 2012 at 8:16
  • that's what I was afraid of Oct 10, 2012 at 14:09
  • @PeterPetersen just in case you aren't already using it or something similar, there's a handy ArcScript for defining the projection of shapefiles/FGDB layers in a folder or FGDB en masse: resources.arcgis.com/gallery/file/arcobjects-net-api/…
    – Dan C
    Oct 11, 2012 at 19:54

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