[gdal-dev] RFC 22: RPC Georeferencing

Tamas Szekeres szekerest at gmail.com
Mon Mar 31 11:26:00 EDT 2008


2008/3/31, Frank Warmerdam <warmerdam at pobox.com>:
> 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?
>

No, since it doesn't contain int array mappings.

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

It seems to be the cheapest approach to handle the outstanding bug:
http://trac.osgeo.org/gdal/ticket/2211

But I'm quite hesitant to make this change because.
1. It wouldn't be prudent to introduce an API change on a function
that is considered to be deprecated.
2. I haven't found any documentation about the WarpOptions XML representation.


I agree that some further considerations would be required about how
to provide a more powerful support for the warp functionality at the
SWIG interface.


Best regards,

Tamas


More information about the gdal-dev mailing list