Do any of the APIs that return error messages say anything? <a href="http://www.gdal.org/ogr/cpl__error_8h.html">http://www.gdal.org/ogr/cpl__error_8h.html</a><div><br></div><div>Also, if multiple processes try to open the same file and stay resident, I am not sure how the FileGDB API will behave. Can you set the worker mpm settings to always have at most 1 process just to test?<br>
<br><div class="gmail_quote">On Sat, Jul 30, 2011 at 12:23 PM, Smith, Michael ERDC-CRREL-NH <span dir="ltr"><<a href="mailto:Michael.Smith@usace.army.mil">Michael.Smith@usace.army.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It is prefork<br>
<br>
[msmith@linux_wms_bm ~]$ httpd -V<br>
Server version: Apache/2.2.15 (Unix)<br>
Server built: Jul 23 2010 05:08:08<br>
Server's Module Magic Number: 20051115:24<br>
Server loaded: APR 1.4.2, APR-Util 1.3.9<br>
Compiled using: APR 1.4.2, APR-Util 1.3.9<br>
Architecture: 64-bit<br>
Server MPM: Prefork<br>
threaded: no<br>
forked: yes (variable process count)<br>
Server compiled with....<br>
-D APACHE_MPM_DIR="server/mpm/prefork"<br>
-D APR_HAS_SENDFILE<br>
-D APR_HAS_MMAP<br>
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)<br>
-D APR_USE_SYSVSEM_SERIALIZE<br>
-D APR_USE_PTHREAD_SERIALIZE<br>
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT<br>
-D APR_HAS_OTHER_CHILD<br>
-D AP_HAVE_RELIABLE_PIPED_LOGS<br>
-D DYNAMIC_MODULE_LIMIT=128<br>
-D HTTPD_ROOT="/opt/mapserver"<br>
-D SUEXEC_BIN="/opt/mapserver/bin/suexec"<br>
-D DEFAULT_PIDLOG="logs/httpd.pid"<br>
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"<br>
-D DEFAULT_LOCKFILE="logs/accept.lock"<br>
-D DEFAULT_ERRORLOG="logs/error_log"<br>
-D AP_TYPES_CONFIG_FILE="conf/mime.types"<br>
-D SERVER_CONFIG_FILE="conf/httpd.conf"<br>
<div><div></div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a>] On Behalf Of Ragi Burhum<br>
Sent: Saturday, July 30, 2011 11:49 AM<br>
To: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>; Daniel Morissette; Even Rouault<br>
Subject: Re: [gdal-dev] FileGDB OGR driver test<br>
<br>
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...<br>
<br>
<br>
> Date: Fri, 29 Jul 2011 23:59:00 +0200<br>
> From: Even Rouault <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>><br>
> Subject: Re: [gdal-dev] FileGDB OGR driver test<br>
> To: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> Cc: Daniel Morissette <<a href="mailto:dmorissette@mapgears.com">dmorissette@mapgears.com</a>><br>
> Message-ID: <<a href="mailto:201107292359.00656.even.rouault@mines-paris.org">201107292359.00656.even.rouault@mines-paris.org</a>><br>
> Content-Type: Text/Plain; charset="iso-8859-1"<br>
><br>
> Le vendredi 29 juillet 2011 23:20:48, Daniel Morissette a écrit :<br>
><br>
> For the record, I've tested your little testfgdb and run it under my<br>
> favorite http server : mongoose.<br>
><br>
> And... it works well...<br>
><br>
><br>
>> A little trivia for the weekend...<br>
>><br>
>> After his Windows vs FGDB adventures, Jeff reported an issue with<br>
>> FGDB on Linux as well, on the Linux server used for the FOSS4G<br>
>> benchmarking exercise and I've had a look.<br>
>><br>
>> I noticed something odd: OGROpen() (the method of the C API) is able<br>
>> to open the FGDB dataset when run at the command line, but is unable<br>
>> to open the same file when run as the same user, but under Apache.<br>
>> (Yes, same user)<br>
>><br>
>> MapServer is out of the equation, I am able to reproduce the problem<br>
>> with the following short program $ cat testfgdb.cpp<br>
>><br>
>> #include "ogr_api.h"<br>
>><br>
>> int main()<br>
>> {<br>
>> OGRDataSourceH hDS = NULL;<br>
>><br>
>> OGRRegisterAll();<br>
>><br>
>> hDS = OGROpen("/tmp/us_states.gdb", FALSE, NULL);<br>
>><br>
>> printf("Content-type: text/plain\n\n");<br>
>> printf("hDS = %x\n", hDS);<br>
>><br>
>> if (hDS)<br>
>> OGRReleaseDataSource( hDS );<br>
>><br>
>> }<br>
>><br>
>><br>
>> When run as at the command line, I get the following output:<br>
>><br>
>> $ ./testfgdb<br>
>> Content-type: text/plain<br>
>><br>
>> hDS = e23a710<br>
>><br>
>><br>
>> ... and when run via the web server I get:<br>
>><br>
>> <a href="http://12.189.158.78:8081/cgi-bin/testfgdb" target="_blank">http://12.189.158.78:8081/cgi-bin/testfgdb</a><br>
>><br>
>> hDS = 0<br>
>><br>
>><br>
>> However, just to make things more confusing, a shell script calling<br>
>> ogrinfo on the same table does work fine via the web server... what<br>
>> does ogrinfo do that my little 3-liner program is missing?<br>
>><br>
>> See for yourself at the following URL and make your guesses...<br>
>><br>
>> <a href="http://12.189.158.78:8081/cgi-bin/ttt" target="_blank">http://12.189.158.78:8081/cgi-bin/ttt</a><br>
>><br>
>> ***** Executing testfgdb program...<br>
>><br>
>> Content-type: text/plain<br>
>><br>
>> hDS = 0<br>
>><br>
>> ***** Executing /opt/mapserver/bin/ogrinfo -fid 1 -geom=summary<br>
>> /tmp/us_states.gdb statesp020<br>
>><br>
>> INFO: Open of `/tmp/us_states.gdb'<br>
>> using driver `FileGDB' successful.<br>
>><br>
>> Layer name: statesp020<br>
>> Geometry: Multi Polygon<br>
>> Feature Count: 2895<br>
>> Extent: (-179.000000, 17.000000) - (179.000000, 71.000000) Layer SRS<br>
>> WKT:<br>
>> GEOGCS["GCS_North_American_1983",<br>
>> DATUM["North_American_Datum_1983",<br>
>> SPHEROID["GRS_1980",6378137.0,298.257222101]],<br>
>> PRIMEM["Greenwich",0.0],<br>
>> UNIT["Degree",0.017453292519943295]]<br>
>> FID Column = OBJECTID<br>
>> Geometry Column = SHAPE<br>
>> AREA: Real (0.0)<br>
>> PERIMETER: Real (0.0)<br>
>> STATESP020: Real (0.0)<br>
>> STATE: String (0.0)<br>
>> STATE_FIPS: String (0.0)<br>
>> OGRFeature(statesp020):1<br>
>> AREA (Real) = 267.357<br>
>> PERIMETER (Real) = 374.768<br>
>> STATESP020 (Real) = 2<br>
>> STATE (String) = Alaska<br>
>> STATE_FIPS (String) = 02<br>
>> MULTIPOLYGON : 1 geometries:<br>
>> POLYGON : 70238 points<br>
>><br>
>> On 11-07-29 11:30 AM, Jeff McKenna wrote:<br>
>>> An update on this issue:<br>
>>><br>
>>> I did some more testing and it seems that I was assuming that<br>
>>> MapServer would use the SHAPEPATH value for the CONNECTION; I was<br>
>>> wrong (in my filegdb testing on Windows I have discovered that this<br>
>>> is not the case here). So to use a relative path you must make sure<br>
>>> your CONNECTION is relative to the mapfile. I have made a note of<br>
>>> this in the docs (<a href="http://www.mapserver.org/input/vector/filegdb.html" target="_blank">http://www.mapserver.org/input/vector/filegdb.html</a>).<br>
>>><br>
>>> Tricky! :)<br>
>>><br>
>>> -jeff<br>
>>><br>
>>> On 11-07-18 8:18 PM, Jeff McKenna wrote:<br>
>>>> More testing feedback:<br>
>>>><br>
>>>> When displaying in MapServer, a full path is required on Windows<br>
>>>> (only Windows, relative paths work on Unix), in the CONNECTION<br>
>>>> parameter, such<br>
>>>> as:<br>
>>>><br>
>>>> FAILS: CONNECTION "filegdb/us_states.gdb"<br>
>>>> WORKS: CONNECTION "C:/ms4w/apps/ms101/data/filegdb/us_states.gdb"<br>
>>>><br>
>>>> I have documented this at<br>
>>>> <a href="http://www.mapserver.org/input/vector/filegdb.html" target="_blank">http://www.mapserver.org/input/vector/filegdb.html</a><br>
>>>><br>
>>>> If others can test this issue: to duplicate, use GDAL-trunk and<br>
>>>> then try to display any FileGDB (created with Arc 10.0) in MapServer, on Windows.<br>
>>>> And let me know if you succeed. Thanks.<br>
>>>><br>
>>>> -jeff<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 5<br>
> Date: Fri, 29 Jul 2011 18:48:37 -0400<br>
> From: "Ian Walberg" <<a href="mailto:ian.walberg@airborne.aero">ian.walberg@airborne.aero</a>><br>
> Subject: [gdal-dev] Build on Redhat 7.x<br>
> To: <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>><br>
> Message-ID:<br>
> <<a href="mailto:D12323219CEDB24AA8FAE53FF3F59FB402DC0F33@be28.exg3.exghost.com">D12323219CEDB24AA8FAE53FF3F59FB402DC0F33@be28.exg3.exghost.com</a>><br>
> Content-Type: text/plain; charset="us-ascii"<br>
><br>
> Folks,<br>
><br>
> We need to be able to guild GDAL on Redhat 7.x as some of the systems<br>
> we deploy to still use it (don't ask)<br>
><br>
> Currently we are using 1.4.1 which was the newest version that we<br>
> could get to build some time ago.<br>
><br>
> However we now need to add spatialite support so need to build a later<br>
> version.<br>
><br>
> Has anyone out there needed to do this?<br>
><br>
> Thanks<br>
><br>
> Ian<br>
><br>
><br>
> ------------------------------<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
> End of gdal-dev Digest, Vol 86, Issue 88<br>
> ****************************************<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br></div>