[Gdal-dev] Coordinate transform problem

[Frank Warmerdam]

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