[gdal-dev] FileGDB OGR driver test

Sat Jul 30 15:23:40 EDT 2011

It is prefork

[msmith at linux_wms_bm ~]$ httpd -V
Server version: Apache/2.2.15 (Unix)
Server built:   Jul 23 2010 05:08:08
Server's Module Magic Number: 20051115:24
Server loaded:  APR 1.4.2, APR-Util 1.3.9
Compiled using: APR 1.4.2, APR-Util 1.3.9
Architecture:   64-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/opt/mapserver"
 -D SUEXEC_BIN="/opt/mapserver/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

-----Original Message-----
From: gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Ragi Burhum
Sent: Saturday, July 30, 2011 11:49 AM
To: gdal-dev at lists.osgeo.org; Daniel Morissette; Even Rouault
Subject: Re: [gdal-dev] FileGDB OGR driver test

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
> ****************************************
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev