[gdal-dev] ngpython and GetSubDataSets()?

Jose Luis Gomez Dans josegomez at gmx.net
Tue Feb 12 13:30:03 EST 2008


Hi,
I've just compiled gdal 1.5.0 on a Linux RHEL5 X86_64 machine. I need to use HDF files extensively, so I've been trying to test whether the new compiled GDAL works. In python, I noticed that I no longer get all the methods I used to get.

In my older version, I had:
In [3]: g=gdal.Open("MOD17A3.A2004366.h19v10.205.2006164124254.hdf")

In [4]: g.Ge
g.GetDescription    g.GetGCPCount       g.GetGCPs           g.GetMetadata       g.GetProjectionRef  g.GetSubDatasets
g.GetDriver         g.GetGCPProjection  g.GetGeoTransform   g.GetProjection     g.GetRasterBand

In [4]: g.GetSubDatasets()
Out[4]:
[('HDF4_EOS:EOS_GRID:"MOD17A3.A2004366.h19v10.205.2006164124254.hdf":MOD_Grid_MOD17A3:Gpp_1km',
  '[1200x1200] Gpp_1km MOD_Grid_MOD17A3 (16-bit unsigned integer)'),
 ('HDF4_EOS:EOS_GRID:"MOD17A3.A2004366.h19v10.205.2006164124254.hdf":MOD_Grid_MOD17A3:Npp_1km',
  '[1200x1200] Npp_1km MOD_Grid_MOD17A3 (16-bit integer)'),
 ('HDF4_EOS:EOS_GRID:"MOD17A3.A2004366.h19v10.205.2006164124254.hdf":MOD_Grid_MOD17A3:Gpp_Npp_QC_1km',
  '[1200x1200] Gpp_Npp_QC_1km MOD_Grid_MOD17A3 (8-bit unsigned integer)')]


In the newly-compiled version, I do exactly the same (get a deprecation warning about the osgeo namespace), but when I do g.GetSubDatasets()...
g.GetSubDatasets()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/ucfajlg/<ipython console>

/usr/lib64/python2.4/site-packages/GDAL-1.5.0-py2.4-linux-x86_64.egg/osgeo/gdal.py in <lambda>(self=<osgeo.gdal.Dataset; proxy of <Swig Object of type 'GDALDatasetShadow *' at 0xbfd3200> >, name='GetSubDatasets')
    493     __swig_getmethods__ = {}
    494     for _s in [MajorObject]: __swig_getmethods__.update(getattr(_s,'__swig_getmethods__',{}))
--> 495     __getattr__ = lambda self, name: _swig_getattr(self, Dataset, name)
        global __getattr__ = undefined
        self = <osgeo.gdal.Dataset; proxy of <Swig Object of type 'GDALDatasetShadow *' at 0xbfd3200> >
        name = 'GetSubDatasets'
        global _swig_getattr = <function _swig_getattr at 0x2aaaaee99050>
        global Dataset = <class 'osgeo.gdal.Dataset'>
    496     def __init__(self): raise AttributeError, "No constructor defined"
    497     __repr__ = _swig_repr

/usr/lib64/python2.4/site-packages/GDAL-1.5.0-py2.4-linux-x86_64.egg/osgeo/gdal.py in _swig_getattr(self=<osgeo.gdal.Dataset; proxy of <Swig Object of type 'GDALDatasetShadow *' at 0xbfd3200> >, class_type=<class 'osgeo.gdal.Dataset'>, name='GetSubDatasets')
     32     method = class_type.__swig_getmethods__.get(name,None)
     33     if method: return method(self)
---> 34     raise AttributeError,name
        global AttributeError = undefined
        name = 'GetSubDatasets'
     35
     36 def _swig_repr(self):

AttributeError: GetSubDatasets

I solved the problem by getting rid of the /usr/lib64/python2.4/site-packages/GDAL-1.5.0-py2.4-linux-x86_64.egg/ directory, which takes me back to the "oldgen" bindings. My question is whether all the methods from the oldgen bindings have already made it to the ng bindings, or whether there will be other changes that will make my software incompatible when the ng switch goes live, and for which I will need to modify my code.

Cheers,
Jose
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser


More information about the gdal-dev mailing list