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 <[email protected]> > 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. >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
