ogr2ogr: globalid read failure with filegdb

[rsadler]

Hi List,

I'm receiving a read failure in extracting a layer from a GDB that was first reported on the gdal-dev list. I'm following up on Even's suggestion to forward this bug listed to trac.osgeo.

After I try and exclude the globalid field using -select, or trying to force a conversion to string, it still needs to read the field before doing the select (or so it seems).

ogr2ogr -overwrite -skipfailures -f "ESRI Shapefile" -fieldTypeToString All -select DATE_,NO_INDIVIDUALS,FOLIAR_COVer,PLANT_FORM,LIFE_STAGE,PERC_SEEDED,CONTRL_METHOD,DISTANCE_ROAD,DIRECTION_ROAD,COMMENTS,FIELD_SOURCE,FIELD_TRIP,SEQNUM,WRA,WSA,WIA,RCP_P,SUBSET,ASSET,WEED_SCIENTIFIC,WEED_COMMON test_shape "Muck_v10.gdb" "BI_Weeds"

toy data set attached

The globalid looks like this (hexadecimal): GLOBALID {1B30983C-3305-46B9-8CE3-784EE73ECDCA} {870EDE4A-7CD7-4484-8972-63FCEE87BAC5} {5DBBE9D3-1568-401A-A13B-9D3ED73229D1} {E612F9C8-E41E-49F8-84B7-B34E7006748D} {E2495A82-3831-4822-9AFD-72ECBF91C18D} {DCABB59C-ED79-4D24-932B-4EA3C870FBD6}

Regards Rohan Sadler

############### gdal-dev] Problem with GUID-field in FileGDB driver Simon Lyngby Kokkendorff silyko at gmail.com Fri Nov 2 02:13:58 PDT 2012

Hi List,

I have been trying to transform some FileGDB databases with OGR and have

run into a problem reading a specific field called "GlobalID". The field simply cannot be read by OGR, which emits this warning (and the field is left as NULL):

ERROR 1: Error: Failed to determine string value for column GlobalID (The value type is incompatible with the field type.)

Have run into the problem both programatically using the OGR C-API, the python bindings and also issuing commands like:

ogr2ogr -f SQLITE -dsco SPATIALITE=YES out.sqlite in.gdb layer_name

(Gdal version 1.9.1)

Have attached a screendump which displays what the field is supposed to look like.

Hope that someone can provide a hint on how to deal with this!

Cheers, Simon Kokkendorff, National Survey and Cadastre of Denmark

The ArcGis resources describe the GlobalID field like this:

Global identifiers

Global ID and GUID data types store registry style strings consisting of 36 characters enclosed in curly brackets. These strings uniquely identify a feature or table row within a geodatabase and across geodatabases. This is how features are tracked in one-way and two-way geodatabase replication. Developers can use them in relationships or in any application requiring globally unique identifiers. In a relationship, if a Global ID field is the origin key, a GUID field must be the destination key. You can add global IDs to a dataset in a geodatabase by right-clicking it in the Catalog tree and clicking Add Global IDs. The geodatabase will then maintain these values automatically. You can create the GUID field as well, but you must maintain its values.

Databases with a native GUID data type, such as personal geodatabases and Microsoft SQL Server, store global ID and GUID values as 16 bytes. Databases without a native GUID data type store them as 38 bytes.

---

An HTML attachment was scrubbed... URL: <​http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121102/2a28398d/attachment-0001.html>

---

A non-text attachment was scrubbed... Name: ExampleGUIDs_NaturalFeaturesP.png Type: image/png Size: 34391 bytes Desc: not available URL: <​http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121102/2a28398d/attachment-0001.png>

[rsadler]

ESRI geodatabase file

[Even Rouault]

Please attach a ZIP file with the whole gdb directory. A .gdb file alone is not a valid geodatabase.

But I believe this is fixed in trunk (r25205) and in branches/1.9 (r25206) (#4882)