gdalnumeric does only support old Numeric package

proposed patch to correct the problem

(From update of attachment 354)
>--- gdalnumeric_old.py	Wed Apr 26 16:02:48 2006
>+++ gdalnumeric.py	Wed Apr 26 16:15:50 2006
>@@ -82,7 +82,11 @@
> import gdal
> import _gdal
> from gdalconst import *
>-from Numeric import *
>+try:
>+	from numpy import *
>+except:
>+	from Numeric import *
>+
> 
> UnsignedInteger = 'u'
> UnsignedInt = 'u'
> 
>@@ -186,8 +190,12 @@
> 
>     if xsize + xoff > band.XSize or ysize + yoff > band.YSize:
>         raise ValueError, "array larger than output file, or offset off edge"
>+ 
>+    try:
>+	datatype = NumericTypeCodeToGDALTypeCode( array.dtype.char )
>+    except:
>+	datatype = NumericTypeCodeToGDALTypeCode( array.typecode() )
> 
>-    datatype = NumericTypeCodeToGDALTypeCode( array.typecode() )
>     if datatype == None:
>         raise ValueError, "array does not have corresponding GDAL data type"
> 

sorry, I went to quickly and posted a patch with some things not needed (nothing
changed ...)

See the Additional Comment #2. 

I can post a clean version of the patch if needed.

Didrik

Mateusz, 

Could you look into this?  I wasn't aware there were two names for
the same package (Numeric and numpy), so please look into this.  I don't
want things confused with numarray though which we aren't really supporting
yet. 

In fact, there are other files int the gdal python files concerned by the
"problem" . The transition from Numeric to numpy is in progress. I can invest
some time to propose a general patch for gdal. 

I think that supporting the two library name is not a big problem. Another
solution is to do like matplotlib that has kind of interface called numerix in
front of Numeric, numpy and numarray.

Didrik

Today, I posted some details related to this issue on the gdal-dev list:
http://lists.maptools.org/pipermail/gdal-dev/2006-May/008843.html

Please, share your comments.

Here is the function using gdalnumeric in my scripts. I cannot provide all the
script because of the lost of dependencies but I could create a little test case
if needed (with an input dataset).

-------------------------------------------------------------------------------
  def save_to_file(self, filename, raster, format="GTiff", driver_options =None,\
                  coords="EPSG:23030", debug=False):
    '''
    '''
    driver = gdal.GetDriverByName( format )
    if driver_options is None :
      driver_options = ['TFW=YES','COMPRESS=DEFLATE']

    dst_ds = driver.Create( filename, len(self.idx['X']),\
                            len(self.idx['Y']), 1, gdal.GDT_UInt16,\
                            driver_options )

    ct = gdal.ColorTable()
    for i in range(8):
      ct.SetColorEntry( i, (255, 255 - i*32, i*32, 255) )
    dst_ds.GetRasterBand(1).SetRasterColorTable( ct )

    # In a north up image, padfTransform[1] is the pixel width, and
    # padfTransform[5] is the pixel height. The upper left corner of
    # the upper left pixel is at position (padfTransform[0],padfTransform[3]).
    dst_ds.SetGeoTransform( [ self.coord['X'][0], \
                            self.coord['X'][1]-self.coord['X'][0],\
                            0, \
                            self.coord['Y'][-1], \
                            0, \
                            self.coord['Y'][0]-self.coord['Y'][1]]
                            )

    srs = osr.SpatialReference()
    #TODO : add a check to see if it worked (problem with GDAL_DATA env)
    ret_val = srs.SetWellKnownGeogCS('ED50');
    srs.SetUTM(30,True)
    dst_ds.SetProjection( srs.ExportToWkt() )


    # I have to transpose the raster because of the line align that is different
    dst_ds.GetRasterBand(1).WriteArray(numpy.transpose(raster))
    dst_ds.FlushCache()
    del(dst_ds)
-------------------------------------------------------------------------------

It's the call to WriteArray that calls gdalnumeric functions.

Didrik

Hi,

I'd like to inform that there is some bigger issue related to 
SWIG based Next-Generation Python bindings to GDAL.
I've just started to investigate it and I hope I'll bring a fix very soon.

This bug report is related to gdalnumeric.py module which is used by both:
- traditional Python bindings - pymod
- SWIG based NG Python bindings

We're going to use new NumPy module only in the NG Python bindings, the
tranditional pymod will use old Numeric module.
Thus, NG Python for GDAL is required to be working well before porting it to NumPy.

So, I'm going to leave this bug report open and take up it soon.

If I understand current state of NG Python bindings correctly, this issue can be closed because Hobu has added support of NumPy?. Should I close it myself or reassign it to Hobu?

I've consulted this issue with Hobu and we've decided to close it as already implemented by Hobu, so it's been fixed.