[Gdal-dev] ogr2ogr on Red Hat Advanced Server 2.1 vs. Red Hat 9

Doug_Newcomb at fws.gov Doug_Newcomb at fws.gov
Wed Sep 3 17:01:35 EDT 2003


Hi Folks,
      I'm running into some strangeness with ogr2ogr .  I am reprojecting
the nwi quadrangle shapefiles  (ftp://www.nwi.fws.gov/shapedata ) using
ogr2ogr called in a perl script  in the following fashion.

 ogr2ogr -t_srs "NAD83" -f "ESRI Shapefile" $destnwi  $nwishape

where $nwishape is the name of the input shape file and $destnwi is the
name of the destination directory.
I have the following as output:

shapedir = /gis/import/nwi/athens/aonia_l.prj  #echoing the input filename
quadname=aonia_l                                                  # echoing
the quad filename
deleting /oracle/data1/gisdata/SERegion/nwi/athens/aonia_l.shp  # delete
the output shape file if it exists

ERROR 4: Failed to open Shapefile
`/oracle/data1/gisdata/SERegion/nwi/athens/aonia_l.shp'.

ERROR 1: Terminating translation prematurely after failed
translation of layer aonia_l

A single file , aonia_l.shp is created with size 0 (according to ls -al) .

This is on a quad Xeon 1.5 GHz box with 4 GB RAM, 8GB swap, and about 400GB
of free space on the destination drive, using the following kernel

Linux xxx.xxx.xxx 2.4.9-e.27enterprise #1 SMP Tue Aug 5 15:39:21 EDT 2003
i686 unknown

rpm -qa |grep glibc gives:

compat-glibc-6.2-2.1.3.2
glibc-devel-2.2.4-32.8
glibc-2.2.4-32.8
glibc-profile-2.2.4-32.8
glibc-common-2.2.4-32.8

The fun thing is that with gdal 1.1.9 (compiled from source)  it works for
some files and then dies.  With the 9/3/2003 cvs-snapshot, it dies on the
first one.

When I run gdal 1.1.9 ( compiled from source ) on a dual Athlon 2000 MP box
with 2GB RAM Red Hat 9 latest 2.4.20 kernel and glibc (via up2date) in the
same manner ( called from a perl script) ogr2ogr works flawlessly.


It's possible that my abuse of perl and ogr have something to do with the
problem :-) .  I can provide more details if requested for debugging, but I
will be running it on the Red Hat 9 box and moving the data back, so this
is not urgent for me.

Doug Newcomb
USFWS
Raleigh, NC















More information about the Gdal-dev mailing list