[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