Actually, it would be quite wise to check that... I've noticed (because I happen to have my working area in a Dropbox folder) the FGDB API creating transient lock files (gah!!) while in operation.
P. On Sat, Jul 30, 2011 at 12:40 PM, Ragi Burhum <[email protected]> wrote: > Do any of the APIs that return error messages say > anything? http://www.gdal.org/ogr/cpl__error_8h.html > 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? > > On Sat, Jul 30, 2011 at 12:23 PM, Smith, Michael ERDC-CRREL-NH > <[email protected]> wrote: >> >> It is prefork >> >> [msmith@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: [email protected] >> [mailto:[email protected]] On Behalf Of Ragi Burhum >> Sent: Saturday, July 30, 2011 11:49 AM >> To: [email protected]; 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 <[email protected]> >> > Subject: Re: [gdal-dev] FileGDB OGR driver test >> > To: [email protected] >> > Cc: Daniel Morissette <[email protected]> >> > Message-ID: <[email protected]> >> > 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" <[email protected]> >> > Subject: [gdal-dev] Build on Redhat 7.x >> > To: <[email protected]> >> > Message-ID: >> > <[email protected]> >> > 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 >> > [email protected] >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > >> > End of gdal-dev Digest, Vol 86, Issue 88 >> > **************************************** >> _______________________________________________ >> gdal-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
