[gdal-dev] RFC 22: RPC Georeferencing

[Tamas Szekeres]

Frank,

I think the proposed SWIG wrapper would be reasonable to expose the
transformer. Some of the %apply statements (like %apply (double
*inout) {(int*)};) should be changed for C# but I'll take care of
this, right after committing the bulk of the code.

But I'm a but uncertain about how the SWIG warp/reproject support will
benefit from this addition. How the internal
GDALCreateGenImgProjTransformer in GDALAutoCreateWarpedVRT will
receive those options you have been introduced with
GDALCreateGenImgProjTransformer2?.

Moreover it's slightly off topic but I wonder if we could add a
support for specifying the GDALWarpOptions from the SWIG API either
(at least for AutoCreateWarpedVRT and ReprojectImage). I agree that it
would be difficult to expose a new class for GDALWarpOptions but we
could possibly utilize GDALDeserializeWarpOptions and specify this
parameter as CPLXMLNode in the API. Recall that CPLXMLNode have
already been added (at least for C#) out there.

Just another comment (still off topic) is that GDALAutoCreateWarpedVRT
is somewhat should be hidden by the VRT driver, and we could utilize
Driver.CreateCopy when creating new VRTs based on existing datasets.
The SUBCLASS option of CreateCopy can do accept VRTWarpedDataset at
the moment only the other creation options like the src and dest WKT-s
should be added.


Best regards,

Tamas




2008/3/30, Frank Warmerdam <warmerdam at pobox.com>:
>
>  Folks,
>
>  It is proposed that GDAL support an additional mechanism for geolocation of
>  imagery based on rational polynomial coefficients (RPCs) represented as metadata.
>
>  Many modern raw satellite products are distributed with RPCs, including
>  products from GeoEye, and DigitalGlobe. RPCs provide a higher systematic
>  description of georeferencing over an image, and also contain information on
>  the viewing geometry that in theory makes orthocorrection (given a DEM) and
>  some 3D operations like building height computation possible.
>
>  To some extent RPCs were already supported in GDAL but the support was
>  incomplete and not well documented.  This RFC revises the approach somewhat
>  and is intended to make this a "fully supported" geolocation method in GDAL.
>
>    http://trac.osgeo.org/gdal/wiki/rfc22_rpc
>
>  Pretty much everything is already implemented and committed, but I'm willing
>  to make changes as needed.  One aspect that I consider very unsettled (and
>  which I have not yet committed) is the SWIG bindings for the GDAL transformer
>  API.  I'd especially appreciate if the SWIG gods could review and propose a
>  better binding approach.  The current bindings result in code like this:
>
>      ds = gdal.Open('data/gcps.vrt')
>      tr = gdal.Transformer( ds, None, [ 'METHOD=GCP_POLYNOMIAL' ] )
>
>      (success,pnt) = tr.TransformPoint( 0, 20, 10, 0 )
>
>  With "pnt" being a 3-tuple.  I don't even see how the TransformPoints
>  function in the proposal (transform an array of points in place) will
>  map in Python.
>
>  This email is a call for feedback, but I'm hoping to put forward a motion
>  to adopt on Monday sometime, so prompt feedback for revisions is
>  encouraged!
>
>  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    | President OSGeo, http://osgeo.org
>
>  _______________________________________________
>  gdal-dev mailing list
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>