I reviewed this a little further. I was mistaken in my first report, the field RDSRCDATE was created as DATE (as opposed to DateTime) and populated with null.
I had mistakenly checked and reported on the field CONST_DATE which is created as an Integer and populated with null. (I don't know if the field is populated in the fgdb.) eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory Supported Formats: -> "ESRI Shapefile" (read/write) -> "MapInfo File" (read/write) -> "UK .NTF" (readonly) -> "SDTS" (readonly) -> "TIGER" (read/write) ... ... Any suggestions? I've been tracking trunk of gdal for about a year, although always in a simple fashion (no plugins etc). I would not necessarily catch something basic. Based on reading this two sites, http://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-su and http://replay.waybackmachine.org/20090301081221/http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html I fixed this by calling it this way, eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogrinfo --formats Now I get eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogr2ogr ODF_Lincoln_Roads_v2.shp ~/Desktop/West_Oregon_Roads.gdb "ODF_Lincoln_Roads" Warning 6: Field RDSRCDATE create as date field, though DateTime requested. Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to 'CONSTRUCTE' Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 RDSRCDATE has dates in it now. So it looks like this was a DateTime field and got successfully demoted to a date field. Thanks, Eli >>> On 4/12/2011 at 11:47 AM, in message <201104122047.20004.even.roua...@mines-paris.org>, Even Rouault <even.roua...@mines-paris.org> wrote: > Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit : >> Even, >> >> How do you configure gdal/ogr to build with the linux api? > > This is a bit involved since there's no ./configure support yet, so I > compile > it "at hand" as a plugin > > Here's the line I use from GDAL root source directory : > > g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport - > Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal - > I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib - > I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI > > You must change the /home/even/filegdb/ paths to where you uncompress the > filegdb API > > And you must define the GDAL_DRIVER_PATH environmenet variable to point to > the > path where ogr_filegdb.so is > >> >> I'm working on getting some example datasets together. >> >> Mike >> >> > Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : >> >> On 04/04/2011 05:05, Ragi Burhum wrote: >> >>> Hello list, >> >>> >> >>> I am trying to test a new version of the FileGDB driver for OGR, but I >> >>> lack enough FileGDBs to test :) >> >> >> >> Is the lack of FileGDBs still an issue? At work, we have several >> >> hundreds of them and I could check if I can make some available. >> > >> > ArcGIS 10 FileGDB's right ? >> > >> > Yes "real" data would be usefull. But it would also be usefull if you (or >> > anyone else) could provide small and freely redistribuable >> > samples (potentially "fake" data) with different types of >> > geometries (1 feature for each geometry type is enough in theory), column >> > types (integer, single, double, string, date), etc.. so that it can be >> > included in the GDAL/OGR autotest suite. >> > >> >>> If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB >> >>> driver (and report back), feel free to grab a gdal-trunk binary I made >> >>> for Windows. >> >> >> >> A related question: will there ever be a FileGDB driver for a >> >> non-Windows OS? Is this feasible at all? >> > >> > Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. >> > Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... >> > ?) >> > >> >> Hermann >> >> _______________________________________________ >> >> gdal-dev mailing list >> >> gdal-dev@lists.osgeo.org >> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > >> > _______________________________________________ >> > gdal-dev mailing list >> > gdal-dev@lists.osgeo.org >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev