[gdal-dev] FileGDB OGR driver test

[Daniel Morissette]

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
>>
>>
>>
>
>


-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000