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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
