Closed dbaston closed 8 months ago
Thank you for all the hard work, Dan.
Thanks for the credit @dbaston! I'm happy to see this work come into fruition. I'll find some time to review today/tomorrow in case I might have any insight for you. 🙂
Attention: 23 lines
in your changes are missing coverage. Please review.
Comparison is base (
f108722
) 50.37% compared to head (6e62988
) 50.77%.
Files | Patch % | Lines |
---|---|---|
src/feature.cpp | 17.64% | 14 Missing :warning: |
src/processor.h | 37.50% | 5 Missing :warning: |
src/operation.h | 77.77% | 2 Missing :warning: |
src/deferred_gdal_writer.cpp | 83.33% | 1 Missing :warning: |
src/raster_sequential_processor.cpp | 83.33% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I'm excited to have had some availability to work on the Python bindings. Talking to some users at FOSS4G-NA, I would say the enthusiasm for moving exactextract directly into the GDAL Python bindings was not universal -- there was more interest in using exactextract with other libraries like rasterio and xarray. So I decided to stick to the original plan and use pybind11. I began with the bindings put together by @jdalrym2 as a starting point and made the following changes:
Feature
)Cell
,Coordinate
, etc.)GDALRasterWrapper
, etc.) so that we do not have GDAL as a build or runtime requirementFeatureSource
andRasterSource
objects in Python. As examples, theGDALFeatureSource
andGDALRasterSource
classes use the GDAL Python bindings to read vector and raster data. You can also stick an arbitrary NumPy array into aNumPyRasterSource
and a list of GeoJSON features into aJSONFeatureSource
if you're not using GDAL. It should be straightforward to write adapters for inputs associated with other common libraries.Some components of @jdalrym2's effort are completely missing here, such as documentation and a
setup.py
configuration. There are clearly needed but I wanted to keep the scope of this PR manageable and, for documentation, I think it makes sense to let the interfaces settle down a bit first. In particular, I plan to implement support for efficiently processing multi-band rasters, like we have inexactextractr
. It's possible that this will force some C++ API changes that impact Python bindings.Because the commit history got messy, I've squashed the bindings work down to a single commit with me and @jdalrym2 as co-authors.