[gdal-dev] FileGDB OGR driver test

[Daniel Morissette]

Oh, BTW, before someone tries to claim the prize by blaming SELinux... 
it's disabled, we already checked that...


On 11-07-29 05:20 PM, Daniel Morissette wrote:
> 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