[gdal-dev] How to wrap a C++ library using GDAL in a Python library?

Sean Gillies sean.gillies at gmail.com
Tue Dec 8 14:16:20 PST 2020


Hi,

Rasterio is different, though. It spreads Python very thickly on top of
GDAL. The state of the art for very thin Python bindings for a C++ project
seems to be pybind11. It's used for numpy's FFT module, based on pocketfft.

If some of you are surprised to see me post again on this thread, it's
because my sean at mapbox.com address is getting marked as spam. I've been
having a private conversation with Even on this list that no one else has
seen. And I thought it was because the clarity and insight of my answers
rendered everyone incapable of comment :)

On Tue, Dec 8, 2020 at 3:06 PM Sean Gillies <sean at mapbox.com> wrote:

>
>
> ---------- Forwarded message ---------
> From: Brendan Ward <bcward at astutespruce.com>
> Date: Tue, Dec 8, 2020 at 11:25 AM
> Subject: Re: [gdal-dev] How to wrap a C++ library using GDAL in a Python
> library?
> To: Alex HighViz <alexhighviz at hotmail.com>
> Cc: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
>
>
> Alex,
>
> see rasterio: https://github.com/mapbox/rasterio
>
> It uses Cython (https://cython.readthedocs.io/en/latest/index.html) to
> wrap GDAL rasters and related functions for use in Python.  You can use
> Cython to wrap C / C++ libraries for use in Python; how much you wrap
> depends on the interface you want between the two.
>
> Hope that helps,
>
> Brendan
>
> On Tue, Dec 8, 2020 at 10:17 AM Alex HighViz <alexhighviz at hotmail.com>
> wrote:
>
>> Hi Paul,
>>
>> Yes there is a generic, "how do I expose a  C++ library to Python users"
>> question. But there is a GDAL specific issue that the main inputs and
>> outputs in my library are raster layers, and I am not sure how to pass
>> those. Especially if my library is using GDAL and the user is using GDAL
>> through Python. I can make my interface completely based on filenames, but
>> that seems inefficient. Is this not a more commonly encountered problem?
>>
>> Thanks, Alex
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>> ------------------------------
>> *From:* Paul Harwood <runette at gmail.com>
>> *Sent:* Tuesday, December 8, 2020 4:46:07 PM
>> *To:* Alex HighViz <alexhighviz at hotmail.com>
>> *Cc:* gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
>> *Subject:* Re: [gdal-dev] How to wrap a C++ library using GDAL in a
>> Python library?
>>
>> I may have misunderstood but I think you are asking the wrong community.
>>
>> You can take your own C++ library and make it available to a Python
>> library - see https://docs.python.org/3/extending/extending.html etc -
>> but this is not the community to ask for advice about that. You can, of
>> course, access GDAL in that c++ library using the c++ API but I don't think
>> that doing so would change how you expose the API from your library in
>> Python ...
>>
>> Perhaps you need to make your question more specific?
>>
>> On Tue, 8 Dec 2020 at 12:37, Alex HighViz <alexhighviz at hotmail.com>
>> wrote:
>>
>> Hello,
>>
>> Could somebody please put me on the right track with the following
>> problem?
>>
>> I have a C++ library that makes use of GDAL for processing raster maps
>> and I would like to wrap some of its features into a Python library to make
>> it accessible to a wider community.
>>
>> I would like my library to present functions that take rasters as input
>> and produce rasters as outputs.  I can modify the C++ side to have the
>> functions work on GDALRasterBands, GDALDatasets, or just on filenames. From
>> my perspective I'd prefer to write any wrapping / boiler plate in C++ and
>> have the Python parts as small as possible.
>>
>> I know this question has been asked before here, but I don't recall the
>> answer and could not find it again. A simple example of "best practice"
>> would be ideal.
>>
>>
>> With many thanks, Alex
>>
>>
-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201208/0204ad90/attachment.html>


More information about the gdal-dev mailing list