[Gdal-dev] Coordinate transform problem

Chapman, Martin MChapman at sanz.com
Mon Oct 18 17:57:13 EDT 2004


Frank,

Thanks for your reply.  I upgraded to proj 4.4.8 and gdal 1.2.3 and the
TransformEx function works perfectly.

New question:  I installed gdal 1.2.3 on windows and it compiled with no
problem.  Now I'm installing on Linux and I'm getting the following
compiler error listed below.  Basically it can't find the geos libs (I
think).  I already have geos loaded on my linux box with
PostGIS/Postgres and I'm wondering if that could be causing the problem
(older geos version).  Question is...do I also need to load geos
seperately from gdal in 1.2.3, or is that part of the gdal source now?

Compile error:

make[1]: Entering directory `/downloads/gdal-1.2.3/ogr'
/bin/sh ../libtool --mode=compile g++ -Wall  -O2    -Iogrsf_frmts -I.
-I../port
-I../gcore -I../ogr -I../alg   -DHAVE_GEOS=1 -I/usr/include -I../port
-c -o ogr
info.o ogrinfo.cpp
 g++ -Wall -O2 -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg
-DHAVE_G
EOS=1 -I/usr/include -I../port -c ogrinfo.cpp  -fPIC -DPIC -o
.libs/ogrinfo.o
 g++ -Wall -O2 -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg
-DHAVE_G
EOS=1 -I/usr/include -I../port -c ogrinfo.cpp -o ogrinfo.o >/dev/null
2>&1
/bin/sh ../libtool --mode=link  g++  ogrinfo.o ../libgdal.la -o ogrinfo
g++ ogrinfo.o -o .libs/ogrinfo  ../.libs/libgdal.so -L/usr/lib -lgeos
-logdi31 -
lgif /usr/lib/libjpeg.so -lpng -lz -ldl -lpq -Wl,--rpath
-Wl,/usr/local/lib
../.libs/libgdal.so: undefined reference to
`geos::WKTReader::WKTReader[in-charg
e](geos::GeometryFactory const*)'
../.libs/libgdal.so: undefined reference to
`geos::DistanceOp::distance()'
../.libs/libgdal.so: undefined reference to
`geos::WKTReader::read(std::basic_st
ring<char, std::char_traits<char>, std::allocator<char> >)'
../.libs/libgdal.so: undefined reference to
`geos::ConvexHull::getConvexHull()'
../.libs/libgdal.so: undefined reference to
`geos::GeometryFactory::GeometryFact
ory[in-charge]()'
../.libs/libgdal.so: undefined reference to
`geos::WKTWriter::WKTWriter[in-charg
e]()'
../.libs/libgdal.so: undefined reference to
`geos::DistanceOp::~DistanceOp [in-c
harge]()'
../.libs/libgdal.so: undefined reference to `typeinfo for
geos::GEOSException'
../.libs/libgdal.so: undefined reference to
`geos::DistanceOp::DistanceOp[in-cha
rge](geos::Geometry const*, geos::Geometry const*)'
../.libs/libgdal.so: undefined reference to
`geos::ConvexHull::~ConvexHull [in-c
harge]()'
../.libs/libgdal.so: undefined reference to
`geos::BufferOp::BufferOp[in-charge]
(geos::Geometry*)'
../.libs/libgdal.so: undefined reference to
`geos::WKTWriter::write(geos::Geomet
ry const*)'
../.libs/libgdal.so: undefined reference to
`geos::ConvexHull::ConvexHull[in-cha
rge](geos::Geometry const*)'
../.libs/libgdal.so: undefined reference to
`geos::BufferOp::getResultGeometry(d
ouble, int)'
../.libs/libgdal.so: undefined reference to `geos::WKTWriter::~WKTWriter
[in-cha
rge]()'
../.libs/libgdal.so: undefined reference to `geos::WKTReader::~WKTReader
[in-cha
rge]()'
collect2: ld returned 1 exit status
make[1]: *** [ogrinfo] Error 1
make[1]: Leaving directory `/downloads/gdal-1.2.3/ogr'
make: *** [ogr-apps] Error 2
[root at martinlinux gdal-1.2.3]#

Thanks,
Martin



-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Saturday, October 16, 2004 7:58 PM
To: Chapman, Martin
Cc: gdal-dev at remotesensing.org
Subject: Re: [Gdal-dev] Coordinate transform problem


Chapman, Martin wrote:
> Frank,
> 
> Ok, that makes sense, but I am a little at a loss at how to use the 
> transform method then.  Previously, I used the Inverse and Forward 
> calls for each point, which let me handle "bad points" on a case by 
> case basis, thus allowing me to convert as many coordinates as 
> feasible...a kind of test the limit as you go type algorithm.  I could

> resort back to that, but in essence then I am rewriting the Transform 
> method.  Would it make sense for me to modify or extend the Transform 
> function to do this. In other words, maybe add another optional 
> parameter to Transform that tells the function to drop bad points, or 
> something like that.  Is that a flawed strategy?  The problem with the

> way Transform works now is that I have to scrub my points up front, 
> not, really knowing what points will process correctly and what ones 
> won't, which leads to several inefficiencies.  What did you mean by 
> "error tolerance"?

Martin,

I'm afraid I am not sure what forward and inverse calls you were
previously using or how that is different from what you do now.

You asked about an optional parameter to Transform that would tell the
function to drop bad points.  Are you aware of the TransformEx() method
on the OGRCoordinateTransformation?

     /**
      * Transform points from source to destination space.
      *
      * This method is the same as the C function OCTTransformEx().
      *
      * @param nCount number of points to transform.
      * @param x array of nCount X vertices, modified in place.
      * @param y array of nCount Y vertices, modified in place.
      * @param z array of nCount Z vertices, modified in place.
      * @param pabSuccess array of per-point flags set to TRUE if that
point
      * transforms, or FALSE if it does not.
      *
      * @return TRUE if some or all points transform successfully, or
FALSE if
      * if none transform.
      */
     virtual int TransformEx( int nCount,
                              double *x, double *y, double *z = NULL,
                              int *pabSuccess = NULL ) = 0;


The pabSuccess array is returned indicating which points successfully
transformed.  Now this only tests whether the underlying PROJ
transformation completely failed - not whether the transformation has
become very lossy. So it won't detect that a Mercator transformation is
degrading as you move far from the central meridian, but it can detect
some complete failures as might happen if you moved "over the horizon"
or if there was no grid shift available for a datum shift.

When I referred to error tolerance, I was thinking of actually
transforming and then inverse transforming the points and checking how
much deviation has occured.  The deviation could be compared to some
error tolerance to decide if a transformation is not longer working well
enough to trust.

But some projections might still invert nearly losslessly but still not
be operating sensibly in a real world sense.

Best regards,
-- 
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent




More information about the Gdal-dev mailing list