Opened 5 years ago

Closed 4 years ago

#7052 closed enhancement (wontfix)

API: GDT_Int8

Reported by: Kurt Schwehr Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: api
Cc:

Description

When gdal_array.OpenArray(numpy_array) creates a GDAL dataset handle from a numpy array, it creates a UINT8 gdal dataset for both signed and unsigned INT8 numpy array. See:

https://trac.osgeo.org/gdal/browser/trunk/gdal/swig/include/gdal_array.i?rev=40118#L422

which says:

  case NPY_BYTE:
  case NPY_UBYTE:
      eType = GDT_Byte;
      break;

In most other places, there are both signed and unsigned 1 byte integers. e.g. NPY_BYTE/NPY_INT8 and NPY_UBYTE/NPY_UINT8

And there is this blog post pointing out the same:

https://borealperspectives.wordpress.com/2014/01/16/data-type-mapping-when-using-pythongdal-to-write-numpy-arrays-to-geotiff/

There is the PIXELTYPE=SIGNEDBYTE hack mentioned in GTiff -- GeoTIFF File Format (#2717 / #3151), but that seems extremely awkward.

So what would it take to add GDT_INT8 to the GDALDataType enum?

https://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdal.h?rev=40164#L59

Is that a reasonable or unreasonable thing to do?

Change History (4)

comment:1 by Even Rouault, 5 years ago

The PIXELTYPE=SIGNEDBYTE is more than a GeoTIFF hack. It is documented in the GDAL data model and used in a number of drivers. So the five minute fix would be to just make sure that NPY_BYTE sets it on the band added to the NUMPYDataset

There are implications through the whole code base in adding a new data type, in algorithms (warping, etc.), in gcore (all funtions like GDALGetDataTypeSize(), GDALCopyWords(), etc..) and in drivers. Drivers that use the PIXELTYPE=SIGNEDBYTE hack should be revised, all CreateCopy()/Create() implementations that have this pattern if (eDT == GDT_CInt16 || ... || ... ) return NULL should also be revised, etc....

It is not impossible, but definitely not a five minute job (as introducing OFTInteger64 per https://trac.osgeo.org/gdal/wiki/rfc31_ogr_64 was not a five minute job :-)) There are also implications for external code using GDAL that must be ready to deal with that new data type. So that would be worth a RFC. While doing it adding support for GDT_UInt64/GDT_Int64 (there are probably tickets about that. I know netCDF could support that) might be a good idea (or at least introducing those enum values in the same batch so external code just needs to be modified once).

comment:2 by Even Rouault, 5 years ago

Regarding GDT_Int64/GDT_UInt64 one difficulty with them is that they are not exactly representable as double, so GetNoDataValue()/SetNoDataValue() aren't going to work reliably

comment:3 by Even Rouault, 5 years ago

Keywords: api added
Summary: GDT_Int8API: GDT_Int8

comment:4 by Even Rouault, 4 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.