Opened 7 years ago
Closed 5 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:
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 , 7 years ago
comment:2 by , 7 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 , 6 years ago
Keywords: | api added |
---|---|
Summary: | GDT_Int8 → API: GDT_Int8 |
comment:4 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
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).