[gdal-dev] VRTComplexSource with a LUT, proposal
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.*
*
*
To set the LUT we have to affect directly two pointers and set the number
of elements. There's no other method to set the LUT.
Maybe in other langage like Python it can be useful. But in C++, I think
it's wrong for encapsulation.
But the worst think in my opinion is the VRTComplexSource destructor :
VRTComplexSource::~VRTComplexSource()
> {
> if (padfLUTInputs)
> VSIFree( padfLUTInputs );
> if (padfLUTOutputs)
> VSIFree( padfLUTOutputs );
> }
The destructor frees the two pointer. This can be an issue if I do that :
> double padfLUTInputs[] = {0,1,2};
double padfLUTOutputs[] = {4,5,6};
complexSource->padfLUTInputs = padfLUTInputs
> ; complexSource->padfLUTOutputs = padfLUTOutputs;
And what happens if I want to change the LUT?
I suggest to add a method VRTComplexSource::setLUT (const double *, const
double *, int), and to make the public attributes protected.
The setLUT method frees the pointers, and clones the tables.
Best regards
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] VRTComplexSource with a LUT, proposal
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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] VRTComplexSource with a LUT, proposal
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 > 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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] VRTComplexSource with a LUT, proposal
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. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Java binding gdal.AutoCreateWarpedVRT question
When get a Dataset Object back from the gdal.AutoCreateWarpedVRT(dataset)
call do I need to call delete on the warped dataset and the original
dataset, or just the original when I am done using the warped dataset?
Sorry I did not understand the javadocs.
Ex
Dataset origDataset= gdal.Open("imagefile.ntf");
Dataset warpedDataset = gdal.AutoCreateWarpedVRT(origDataset, wkt);
// do some stuff with the wrapped dataset
// .
//should i delete both?
origDataset.delete();
warpedDataset.delete();
Thanks!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Upgraded to 1.9 - Python Bindings Error
On 05/04/2012 08:16 PM, Jay L. wrote:
List,
Just upgraded to 1.9.0 on my windows 7 machine and I can no longer
access gdal via the python bindings. Command line (ogr2ogr, gdalinfo,
etc. are functioning as expected). Specifically, running 'from osgeo
import gdal', returns:
File "C:\Python26\ArcGIS10.0\lib\site-packages\osgeo\__init.py__",
line 17, in
swig_import_helper
_mod = imp.load_module('_gdal', fp, pathname, descritpion)
ImportError: DLL load failed: The specified procedure could not be found.
GDAL 1.8 was working wonderfully with ArcGIS. No environmental
variables were altered between installations. Path still contains
C:\Program Files (x86)\GDAL and GDAL_DATA is stills set to C:\Program
Files (x86)\GDAL\gdal-data.
I did try adding the PYTHONPATH variable and setting that to
C:\Python26\ArcGIS10.0, but no change in the error.
GDAL1.9 and the python bindings were downloaded from
http://www.gisinternals.com/sdk/ (the MSVC2010-32bit stable version).
Python 2.6 that comes with ArcGIS 10 was compiled with MSVC2008. That
could be the reason why the bindings aren't working. Try uninstalling
and then installing the matching version.
-marius
Oddly, the gdal python utilities are functioning. That is
gdal2tiles.py for example.
Any suggestions appreciated. I assume a PATH error that I am missing,
but am stumped. The mailing list archives were sparse on this error...
Thanks,
Jay
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
