openfgdb from head complains converting this file, but gdal 2.0 converted without complaint

[Kurt Schwehr]

This sample file was able to convert with older versions of GDAL, but seems to fail now. I suspicious that the measured functionality is the trigger.

Seen with Esri ArcMap 10.2.1.3497 and the attached file is from 10.2.2.3552

It is definitely a bug that these error messages don't tell the user what is going on.

And was there a regression with the openfilegdb?

ogr2ogr -f "ESRI Shapefile" sample sample_polyline_zm.gdb.zip 
Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng'
ERROR 1: Error occurred in filegdbtable.cpp at line 2375
ERROR 1: Error occurred in filegdbtable.cpp at line 2609
ERROR 1: Error occurred in filegdbtable.cpp at line 2375

[SNIP]

RROR 1: Error occurred in filegdbtable.cpp at line 2375
ERROR 1: Error occurred in filegdbtable.cpp at line 2609

ogrinfo -mdd all -so -al -fields=YES -geom=YES sample_polyline_zm.gdb.zip 
Had to open data source read-only.
INFO: Open of `sample_polyline_zm.gdb.zip'
      using driver `OpenFileGDB' successful.

Layer name: line
Geometry: 3D Measured Multi Line String
Feature Count: 24
Extent: (-2713433.645832, 2186334.117191) - (-2712962.227713, 2187288.170222)
Layer SRS WKT:
PROJCS["USA_Contiguous_Albers_Equal_Area_Conic_USGS_version",
    GEOGCS["GCS_North_American_1983",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["longitude_of_center",-96.0],
    PARAMETER["Standard_Parallel_1",29.5],
    PARAMETER["Standard_Parallel_2",45.5],
    PARAMETER["latitude_of_center",23.0],
    UNIT["Meter",1.0],
    AUTHORITY["ESRI","102039"],
    VERTCS["NAD_1983",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PARAMETER["Vertical_Shift",0.0],
        PARAMETER["Direction",1.0],
        UNIT["Meter",1.0],
        AUTHORITY["ESRI","115702"]]]
FID Column = OBJECTID
Geometry Column = Shape
Shape_Length: Real (0.0)

ogrinfo -mdd all -so -al -fields=YES -geom=YES sample
INFO: Open of `sample'
      using driver `ESRI Shapefile' successful.

Layer name: line
Metadata:
  DBF_DATE_LAST_UPDATE=2016-05-25
Geometry: 3D Line String
Feature Count: 24
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
Layer SRS WKT:
PROJCS["USA_Contiguous_Albers_Equal_Area_Conic_USGS_version",
    GEOGCS["GCS_North_American_1983",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["longitude_of_center",-96.0],
    PARAMETER["Standard_Parallel_1",29.5],
    PARAMETER["Standard_Parallel_2",45.5],
    PARAMETER["latitude_of_center",23.0],
    UNIT["Meter",1.0],
    VERTCS["NAD_1983",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PARAMETER["Vertical_Shift",0.0],
        PARAMETER["Direction",1.0],
        UNIT["Meter",1.0]]]
Shape_Leng: Real (24.15)

[Kurt Schwehr]

FGDB example that causes complaints from OpenFGDB

[Even Rouault]

In 34295:

OpenFileGDB: do not error out on geometries that have a declared M array but that is missing (closes #6528)

[Even Rouault]

In 34296:

OpenFileGDB: do not error out on geometries that have a declared M array but that is missing (closes #6528)

[Even Rouault]

Was indeed due to M support. It seems that there's a trick used by ArcGIS to put a dummy byte at value 66 to indicate that the M array is in fact not included.

Can the dataset be used for autotest ? (actually could you try to strip it a bit? Particularly the system table a00000004.gdbtable that contains lots of uninteresting XML. Well I could also just take the user table since OpenFileGDB can handle it standalone)

Regarding error messages, I agree it is not user friendly, but error messages even in natural language are rarely helpful to users and developers. Here I find it is really helpful for the developer in a bug report.

[Kurt Schwehr]

Thanks for the patch!

It is fine to use the attached file for testing. I will ask the engineer who made the file to strip it down more if he can.

Roger on the error message. Now we have a ticket that people can bump into.

[Kurt Schwehr]

A smaller example

[Even Rouault]

trunk r34301 "ogr_openfilegdb.py: Read a MULTILINESTRING ZM with a dummy M array (reference #6528)"