[gdal-dev] FileGDB OGR driver test

Paul Ramsey pramsey at opengeo.org
Sun Jul 31 18:30:18 EDT 2011 

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 <ragi at burhum.com> 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
> <Michael.Smith at usace.army.mil> wrote:
>>
>> 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
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>

More information about the gdal-dev mailing list