KEALib provides an implementation of the GDAL data model. The format supports raster attribute tables, image pyramids, meta-data and in-built statistics while also handling very large files and compression throughout.
It attempts to make the Python bindings (mainly for access to the 'neighbours' functionality) more usable with the following changes:
Actually compile successfully against recent versions of awkward-array. Thanks to @agoose77 and @jpivarski for their kind help here. Awkward arrays are used for reading and writing an extra field in the Raster Attribute Table which is the (spatially) neighbouring rows for each class. This is mainly used for processing outputs of a segmentation, which is a common use case for KEA - and ideal for awkward arrays since they can vary in size enormously. GDAL does not have access to this (and fair enough, it's a KEA format specific feature). Also in this PR as a kind of experiment I've added reading and writing of rows of string columns as awkward arrays. GDAL does this as 2D arrays of strings which is kind of clunky. I've also increased the use of pybind11 (as used in the awkward-array examples) to make things consistent.
Add some other KEA specific features: a) creating boolean columns and reading and writing to them as bools - GDAL does not support creation of this column type but can read and write them as ints from/to a KEA file and b) access int columns as int64's - which is how they are actually stored in KEA - GDAL only allows access to them as int32's.
De-couple these Python bindings from GDAL somewhat. Because I assume that most users of this functionality will already have the file open as a GDAL dataset, I accept this as the handle to operate on. Otherwise I'd be forced to reproduce all the functionality GDAL already provides which seems unnecessary. However this creates a circular dependency with GDAL when building. I've worked around this by only linking to GDAL at runtime and faking enough of the GDAL functionality for testing. See the comments at the top of fakegdal.cpp. I think this is an important step and will allow building of these bindings on conda-forge which wasn't possible before.
As a result of not having access to full GDAL (see above) add enough functionality for building the neighbours and running a test suite without GDAL (ie be able to just use extrat module for this).
I envisage this module as kind of a testing ground for KEA specific features. Some things may be moved into GDAL, or otherwise changed - just be warned there could be some churn before we settle what this will look like.
Apologies for the size of this PR.
It attempts to make the Python bindings (mainly for access to the 'neighbours' functionality) more usable with the following changes:
pybind11(as used in the awkward-array examples) to make things consistent.fakegdal.cpp. I think this is an important step and will allow building of these bindings on conda-forge which wasn't possible before.extratmodule for this).I envisage this module as kind of a testing ground for KEA specific features. Some things may be moved into GDAL, or otherwise changed - just be warned there could be some churn before we settle what this will look like.
cc: @neilflood @petebunting @bhjolly @shepjd @petescarth