[gdal-dev] FileGDB OGR driver test

[Even Rouault]

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