Users want to “pip install OTB” in their own environment and mix OTB with well-known Python libraries they trust (as rasterio, numpy, scikit-learn, etc.). They trust the OTB pipeline to use efficiently memory/CPU resources… Finally, a more “pythonic” API would help the use and integration for Python / Scientific developers.

More and more developers go toward developing hybrid remote modules, with both OTB applications (C++) and Python scripts : some efforts could be made to ease the installation of such remote modules. There are a lot of Remote Modules but their status (who maintains the code) must be clear.

Is OTB-core a dream ? What seems obvious for everyone is that the preprocessing applications (optical and SAR calibration, pansharpening, orthorectification, superimpose, …) and SAR modules are specific to OTB and are essential to our toolbox. OTB users trust these applications and are also confident in their outputs. They also like the streaming and threading abilities made possible by ITK/OTB pipeline.

On the other hands, the use of some specific packages (ex : Machine Learning) may decrease, despite some specific features (e.g. sample selection framework) we cannot find in classical Python libraries (e.g. scikit-learn, for machine learning algorithms).

The idea could be to gather essential applications in an “OTB core” library and specific needs in satellites remote modules. We could also imagine to provide some examples of processing chains to define which applications could stay in OTB core or be delivered in a separate remote module.

As already observed in our user survey, users have a lot of expectations regarding the Python API and the OTB packaging (lighter packaging / on-demand installation).  A hard task is to deal with GDAL integration, since a lot of famous libraries (rasterio, geopandas, etc.) are also based upon it and users don’t want to handle libraries conflicts.

QGIS is also a most reliable tool in SIG world and OTB’s integration is a must.

The idea is to go toward a “light and long-term support OTB”. “Light” because we would support less targets (ie : Linux, Windows and drop Mac OS supports – instead, a docker image could fit Mac OS users) and offer less interfaces (drop QT interfaces and Monteverdi but support QGIS integration). And “long-term support” because we will focus on core features of OTB and may deliver some applications as remote modules : their maintenance cycle could differ but OTB continuous integration could guarantee compatibility.

OTB would continue to integrate new sensors and the new packaging would help to integrate in remote sensing processing chains.