[gdal-dev] VRTComplexSource with a LUT, proposal

Even Rouault even.rouault at mines-paris.org
Sat May 19 14:11:01 EDT 2012


Le samedi 19 mai 2012 18:58:05, Saâd HESSANE a écrit :
> 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 :)

I agree the encapsulation isn't ideal, but unless I'm wrong, this class is 
*not* in the public API. It is not marked as CPL_DLL exported, so on Windows, 
you should not be able to access it from the outside of the GDAL lib. On 
Unix/Linux, as, by default (unless GDAL is configured with --hide-internal-
symbols), all symbols are exported, you can technically use it however.

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

There's always a trade off between exposing API and increasing maintenance 
burden. The more API you expose, the more difficult it is to make changes 
afterwards.

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

You don't need another dependency. You can use the CPL minixml API (see 
cpl_minixml.h) that is used by the VRT driver itself for example.

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

If you can come with a patch, I'll consider including it, but I still believe 
you should not rely on that.


More information about the gdal-dev mailing list