Opened 18 years ago
Last modified 17 years ago
#1166 closed defect
gdalnumeric does only support old Numeric package — at Version 8
Reported by: | Owned by: | Mateusz Łoskot | |
---|---|---|---|
Priority: | high | Milestone: | 1.4.1 |
Component: | GDAL_Raster | Version: | 1.3.1 |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
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.
Change History (9)
by , 18 years ago
Attachment: | gdalnumeric_1.3.1.patch added |
---|
comment:1 by , 18 years ago
(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" >
comment:2 by , 18 years ago
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
comment:3 by , 18 years ago
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.
comment:4 by , 18 years ago
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
comment:5 by , 18 years ago
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.
comment:6 by , 18 years ago
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
comment:7 by , 18 years ago
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.
comment:8 by , 17 years ago
Description: | modified (diff) |
---|
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?
Note:
See TracTickets
for help on using tickets.
proposed patch to correct the problem