Jeshua Lacock wrote:
I am the closest I have ever been to compiling the GDAL lib, for Grass
support, and I get the error below:
/usr/bin/ld: table of contents for archive: /usr/src/gdal-1.1.4/gdal.a
is out of date; rerun ranlib(1) (can't load from it)
/usr/bin/ld: table of contents for archive: /usr/src/gdal-1.1.4/gdal.a
is out of date; rerun ranlib(1) (can't load from it)
make[1]: *** [gdalinfo] Error 1
make: *** [apps-target] Error 2
So I ran and ran and re-ran ranlib only to get the error below:
ranlib /usr/src/gdal-1.1.4/gdal.a
ranlib: file: /usr/src/gdal-1.1.4/gdal.a(pnggccrd.o) has no symbols
ranlib: file: /usr/src/gdal-1.1.4/gdal.a(pngvcrd.o) has no symbols
ranlib: file: /usr/src/gdal-1.1.4/gdal.a(tif_pixarlog.o) has no symbols
For each of the three corresponding source files, the entire file is
enclosed in a #if[def]/#endif. The result will be an object file with
no symbols. It would appear that your version of ranlib doesn't like
this (i.e. it fails to update the index, rather than just ignoring the
files).
Try manually removing the above files from the archive, with
ar d gdal.a pnggccrd.o pngvcrd.o tif_pixarlog.o
Then re-run ranlib.
--
Glynn Clements <glynn.clements@virgin.net>
From neteler Sun May 27 19:45:31 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id TAA08080; Sun, 27 May 2001 19:45:31 +0100
Date: Sun, 27 May 2001 19:45:20 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: "Roger S. Miller" <rgrmill@rt66.com>
Cc: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Re: [GRASSLIST:1874] Re: Importing USGS SDTS DLG maps fromdifferingdatums? I'm confused. [very long]
Message-ID: <20010527194520.A8009@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: "Roger S. Miller" <rgrmill@rt66.com>,
grass5 developers list <grass5@geog.uni-hannover.de>
References: <200105240609.AAA05266@inago.swcp.com> <Pine.OS2.3.92.1010524150459.1704B-100000@dakota> <20010524185506.C2571@calico.local> <3B0DD67E.F9123FB9@rt66.com> <"from <20010524215843.B5353@calico.local> <20010526184430.C12157@hgeo02.geog.uni-hannover.de> <3B1004E5.F485BC68@rt66.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B1004E5.F485BC68@rt66.com>; from rgrmill@rt66.com on Sat, May 26, 2001 at 01:32:53PM -0600
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 3833
Lines: 82
Hi Roger
(cc to grass5 as it will be of interest)
On Sat, May 26, 2001 at 01:32:53PM -0600, Roger S. Miller wrote:
Markus Neteler wrote:
> >From GRASS 5.1 onwards GRASS will use the latest PROJ 4.x software available
> from http://www.remotesensing.org/proj/ maintained by Frank Warmerdam
> including datum transform.
Markus,
Thanks for the information. It good to know that datum shifts will
eventually be added. Right now we have a very unfortunately situation.
I think it would be a mistake to release GRASS 5.0 without changing it's
documentation; probably the projection programs need some kind of trap
added to prevent people from using them for datum shifts.
yes, I agree 100%.
Everyone I know of who uses geographic data deals with conversions
between NAD27 and NAD83. Probably anyone in the US who has used GRASS
in the last few months to do more than run tutorials has used GRASS to
convert between NAD83 and NAD27 data. They have every reason to expect
that the conversion works as described. But it doesn't. Their data are
now corrupt.
.. which is a very unfortunate situation!
My experience... Ground water rights in this area are administered by
the State of New Mexico, using a ground water model that was built using
ArcInfo on a lambert conformal conic base, using NAD27. Like everyone
else in this area who deals with ground water planning, I have to
maintain a working version of that model. My GRASS database includes a
location for lambert conformal conic, NAD27 datum to support that model.
I spent a day in the field back in March with a consultant who
represented "the other side" in a ground water permit hearing. We
surveyed (with their GPS) the location of each of my clients' wells, and
the location of
their sewage outfall on the left bank of the Rio Grande. They forwarded
the results to me after we got back to the office, using UTM, NAD83 in
an ESRI format. I built a location for UTM zone 13, NAD83 datum,
converted their surveyed points to GRASS format and then used v.proj to
put them in my lambert conformal conic, NAD27 location. I (and every
other GRASS user) had every reason to believe that the reprojection was
correct. There were no errors. There were no warnings.
The surveyed locations didn't come out to where they were supposed to
be, in fact two of the wells fell within the right-of-way for an
Interstate Highway. However, the ground water model has a fairly coarse
grid in that area and all of the wells fell within the same model cell
where I already simulated them, so the location error wasn't a problem.
It was more of a problem that the sewage outfall fell on the right bank
of the Rio Grande rather than on the left bank.
I was lucky in this instance that the model grid was coarse and that the
exact location of the sewage outfall wasn't very important. I think you
can see that much more serious consequences are possible.
Roger Miller
Lee Wilson and Associates
in my opinion a full migration to latest PROJ4 *including* the datum shift
should not be a big task. GRASS is using a few wrapper functions to PROJ4
(src/libes/proj). As *.proj use these wrapper functions, a datum shift
supported by PROJ4 should be available then to these GRASS functions as
well through the wrapper (or not?).
We should consider to upgrade PROJ4 already in 5.0 and not postpone it
to 5.1. Say, at least *.proj should take care of the datum shift.
Nowadays it will be somewhat hard to explain why GRASS 5.0.0stable still
won't do datum transforms. As not too much is left for the stable release,
but many, many changes awaiting for 5.1, I suggest to upgrade PROJ4 now.
If I am totally wrong, please don't hesiate to tell me 
Regards
Markus Neteler