[gdal-dev] FileGDB OGR driver test

Ragi Burhum ragi at burhum.com
Sat Jul 30 15:40:39 EDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110730/f349c84e/attachment.html


More information about the gdal-dev mailing list