[gdal-dev] FileGDB OGR driver test

Sat Jul 30 11:49:15 EDT 2011

Wild guess, you are using Apache Multithreaded. If you try on Apache prefork, and it works, it is a threading issue with the FileGDB API. The script version of your test would work because it spawns a brand new process. Just guessing...

> Date: Fri, 29 Jul 2011 23:59:00 +0200
> From: Even Rouault <even.rouault at mines-paris.org>
> Subject: Re: [gdal-dev] FileGDB OGR driver test
> To: gdal-dev at lists.osgeo.org
> Cc: Daniel Morissette <dmorissette at mapgears.com>
> Message-ID: <201107292359.00656.even.rouault at mines-paris.org>
> Content-Type: Text/Plain;  charset="iso-8859-1"
> 
> Le vendredi 29 juillet 2011 23:20:48, Daniel Morissette a écrit :
> 
> For the record, I've tested your little testfgdb and run it under my favorite 
> http server : mongoose.
> 
> And... it works well...
> 
> 
>> A little trivia for the weekend...
>> 
>> After his Windows vs FGDB adventures, Jeff reported an issue with FGDB
>> on Linux as well, on the Linux server used for the FOSS4G benchmarking
>> exercise and I've had a look.
>> 
>> I noticed something odd: OGROpen() (the method of the C API) is able to
>> open the FGDB dataset when run at the command line, but is unable to
>> open the same file when run as the same user, but under Apache. (Yes,
>> same user)
>> 
>> MapServer is out of the equation, I am able to reproduce the problem
>> with the following short program
>> $ cat testfgdb.cpp
>> 
>> #include "ogr_api.h"
>> 
>> int main()
>> {
>>   OGRDataSourceH hDS = NULL;
>> 
>>   OGRRegisterAll();
>> 
>>   hDS = OGROpen("/tmp/us_states.gdb", FALSE, NULL);
>> 
>>   printf("Content-type: text/plain\n\n");
>>   printf("hDS = %x\n", hDS);
>> 
>>   if (hDS)
>>     OGRReleaseDataSource( hDS );
>> 
>> }
>> 
>> 
>> When run as at the command line, I get the following output:
>> 
>> $ ./testfgdb
>> Content-type: text/plain
>> 
>> hDS = e23a710
>> 
>> 
>> ... and when run via the web server I get:
>> 
>> http://12.189.158.78:8081/cgi-bin/testfgdb
>> 
>> hDS = 0
>> 
>> 
>> However, just to make things more confusing, a shell script calling
>> ogrinfo on the same table does work fine via the web server... what does
>> ogrinfo do that my little 3-liner program is missing?
>> 
>> See for yourself at the following URL and make your guesses...
>> 
>> http://12.189.158.78:8081/cgi-bin/ttt
>> 
>> ***** Executing testfgdb program...
>> 
>> Content-type: text/plain
>> 
>> hDS = 0
>> 
>> ***** Executing /opt/mapserver/bin/ogrinfo -fid 1 -geom=summary
>> /tmp/us_states.gdb statesp020
>> 
>> INFO: Open of `/tmp/us_states.gdb'
>>       using driver `FileGDB' successful.
>> 
>> Layer name: statesp020
>> Geometry: Multi Polygon
>> Feature Count: 2895
>> Extent: (-179.000000, 17.000000) - (179.000000, 71.000000)
>> Layer SRS WKT:
>> 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]]
>> FID Column = OBJECTID
>> Geometry Column = SHAPE
>> AREA: Real (0.0)
>> PERIMETER: Real (0.0)
>> STATESP020: Real (0.0)
>> STATE: String (0.0)
>> STATE_FIPS: String (0.0)
>> OGRFeature(statesp020):1
>>   AREA (Real) = 267.357
>>   PERIMETER (Real) = 374.768
>>   STATESP020 (Real) = 2
>>   STATE (String) = Alaska
>>   STATE_FIPS (String) = 02
>>   MULTIPOLYGON : 1 geometries:
>>     POLYGON : 70238 points
>> 
>> On 11-07-29 11:30 AM, Jeff McKenna wrote:
>>> An update on this issue:
>>> 
>>> I did some more testing and it seems that I was assuming that MapServer
>>> would use the SHAPEPATH value for the CONNECTION; I was wrong (in my
>>> filegdb testing on Windows I have discovered that this is not the case
>>> here). So to use a relative path you must make sure your CONNECTION is
>>> relative to the mapfile. I have made a note of this in the docs
>>> (http://www.mapserver.org/input/vector/filegdb.html).
>>> 
>>> Tricky! :)
>>> 
>>> -jeff
>>> 
>>> On 11-07-18 8:18 PM, Jeff McKenna wrote:
>>>> More testing feedback:
>>>> 
>>>> When displaying in MapServer, a full path is required on Windows (only
>>>> Windows, relative paths work on Unix), in the CONNECTION parameter, such
>>>> as:
>>>> 
>>>> FAILS: CONNECTION "filegdb/us_states.gdb"
>>>> WORKS: CONNECTION "C:/ms4w/apps/ms101/data/filegdb/us_states.gdb"
>>>> 
>>>> I have documented this at
>>>> http://www.mapserver.org/input/vector/filegdb.html
>>>> 
>>>> If others can test this issue: to duplicate, use GDAL-trunk and then try
>>>> to display any FileGDB (created with Arc 10.0) in MapServer, on Windows.
>>>> And let me know if you succeed. Thanks.
>>>> 
>>>> -jeff
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 29 Jul 2011 18:48:37 -0400
> From: "Ian Walberg" <ian.walberg at airborne.aero>
> Subject: [gdal-dev] Build on Redhat 7.x
> To: <gdal-dev at lists.osgeo.org>
> Message-ID:
>    <D12323219CEDB24AA8FAE53FF3F59FB402DC0F33 at be28.exg3.exghost.com>
> Content-Type: text/plain;    charset="us-ascii"
> 
> Folks,
> 
> We need to be able to guild GDAL on Redhat 7.x as some of the systems we
> deploy to still use it (don't ask)
> 
> Currently we are using 1.4.1 which was the newest version that we could
> get to build some time ago.
> 
> However we now need to add spatialite support so need to build a later
> version.
> 
> Has anyone out there needed to do this?
> 
> Thanks
> 
> Ian
> 
> 
> ------------------------------
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> End of gdal-dev Digest, Vol 86, Issue 88
> ****************************************