[gdal-dev] RFC 22: RPC Georeferencing

[Frank Warmerdam]

Tamas Szekeres wrote:
> 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.

Tamas,

Ok.  Does this imply the OGR transformer should also be updated?

> 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?.

GDALCreateGenImgProjTransformer() becomes deprecated, and some/all
things using it currently will be upgraded to use the new function.
The old function will be reimplemented to call the new function.

I haven't currently proposed updating GDALAutoCreateWarpedVRT()
to use the new GDALCreateGenImgProjTransformer2() function but
it likely ought to be.  And then to pass in the generalized options
we would need a GDALAutoCreateWarpedVRT2().  Grr.

> 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.

This might be desirable, but as in the past I'm hesitant to cast
too much of this stuff in stone via SWIG.  I do think that it is
beyond the scope of this RFC.  What this RFC does do is give a
start to swig binding of the transformer api which would feed into
more generalized warp support which would require (I think) another
RFC.

> 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.

This is a plausible approach.  Possibly we should deprecate
GDALAutoCreateWarpedVRT() and implement a CreateCopy based mechanism
that utilizes GDALCreateGenImgProjTransformer2().

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