Ticket #1166 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

gdalnumeric does only support old Numeric package

Reported by: dpinte@itae.be Assigned to: mloskot
Priority: high Milestone: 1.4.1
Component: GDAL_Raster Version: 1.3.1
Severity: normal Keywords:
Cc:

Description (Last modified by mloskot)

Hi,

Since the changes with Numeric, numpy and scipy integration, the Numeric package
won't be used for a long time. 

I've made a little patch for pymod/gdalnumeric.py in order to correct the problem.
It's still backward compatible.

I will attach it here.

Attachments

gdalnumeric_1.3.1.patch (1.4 kB) - added by dpinte@itae.be on 04/26/06 11:26:20.
proposed patch to correct the problem

Change History

04/26/06 11:26:20 changed by dpinte@itae.be

  • attachment gdalnumeric_1.3.1.patch added.

proposed patch to correct the problem

04/26/06 11:28:30 changed by dpinte@itae.be

(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"
> 

04/26/06 11:29:44 changed by dpinte@itae.be

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

04/26/06 12:30:34 changed by warmerdam

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. 

05/10/06 05:09:17 changed by dpinte@itae.be

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

05/10/06 21:31:35 changed by mloskot

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.

05/11/06 04:49:13 changed by dpinte@itae.be

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

05/15/06 14:03:52 changed by mloskot

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.

03/31/07 04:34:47 changed by mloskot

  • description changed.

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?

03/31/07 09:44:36 changed by mloskot

  • status changed from new to assigned.

03/31/07 09:45:20 changed by mloskot

  • status changed from assigned to closed.
  • resolution set to fixed.

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

03/31/07 09:47:16 changed by mloskot

  • version changed from unspecified to 1.3.1.
  • milestone set to 1.4.0.

03/31/07 13:12:20 changed by warmerdam

  • milestone changed from 1.4.0 to 1.4.1.