[gdal-dev] VRTComplexSource with a LUT, proposal

[Saâd HESSANE]

Hi Even and thank you for the quick response.

You should even not consider the VRTComplexSource class to be in the public
> API, so the visibility of its members is not significant. And playing with
> them
> from the outside isn't recommanded at all.


The fact that you don't consider the class in the public API does not
excuse the fact that this is a mistake encapsulation :)
And apart from that, nothing prevents me to use a special driver to do
specific things that are not directly provided by the public API.
Currently I need to build a VRT, and the VRT driver are fine for that. It's
dirrectly use in the gdalbuildvrt utility for example. If the VRT plugin is
not safe to use, the solution is to correct it.

The only official way of changing the LUT is to change the XML of the VRT
> and
> reload it.

To read a VRT file outside from gdal I need to parse an XML file, so I have
to use another dependency (like xerces) to do just a small think.

Another argument is the VRTKernelFiltredSource. To set a kernel filtre we
don't have to set the attributes nKernelSize, padfKernelCoefs and
bNormalized, because we can't (the attributes are protected). But the API
offers a setKernel that do exactly the same think that I hope the setLUT
method do in the VRTComplexSource.

Best regards

2012/5/19 Even Rouault <even.rouault at mines-paris.org>

> Le samedi 19 mai 2012 16:58:07, Saâd HESSANE a écrit :
> > Hi,
> >
> > In wanting to add programmatically a LUT to a VRTComplexSource, I read
> the
> > VRT driver source code.
> > VRTComplexSource have three public attributes : *double
> > *padfLUTInputs*, *double
> > *padfLUTOutputs* and *int nLUTItemCount.*
> > *
> > *
>
> You should even not consider the VRTComplexSource class to be in the public
> API, so the visibility of its members is not significant. And playing with
> them
> from the outside isn't recommanded at all.
>
> The only official way of changing the LUT is to change the XML of the VRT
> and
> reload it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120519/3bf73393/attachment.html