support for OTB provider plugin in QGIS
What changes will be made and why they would make a better Orfeo ToolBox?
QGIS OTB plugin is one of the most significant part of OTB user community. Many OTB users rely on qgis to run otb applications (a.k.a otb algorithms). Due to our user requirements we should have a stable long term support of OTB in QGIS.
Initial work for QGIS-OTB started long ago with qgis plugin and later it was integrated to qgis processing. Below are some of the issues/concerns for maintainer of this plugin:
- Updating qgis plugin is a tedious task. This is due to update of source code and xml files for every version of OTB. With three month release cycle, this involve more man hours spend solely on plugin and is not a pleasant trip for developers.
- Most of the bugs reported in QGIS-OTB was later found fixed in upstream.
- But this new version(s) of OTB cannot be tested easily without updating plugin code.
- Last but not the least, configure of OTB in qgis are error prone and ends up mostly in not using OTB
The idea is add a new module in OTB that will provide the necessary descriptor for qgis plugin. This module can be part of core and is independent of QGIS!. The binaries provided in this module will be distributed inside OTB binary packages.
High level description
NEW: Modules/Wrappers/QGIS (yet to be implemented) This module will allow to create descriptor files on the fly for any valid otb application. This means users are allowed to use their own custom (free, non-free, remote) otb application, and things will works smoothly.
Not all of the changes are pushed into OTB. The otb qgis plugin (processing algo) is deployed to qgis plugin repository.( changed in qgis3) The plugin will allow user to download otb's binary package (latest) so that it requires less configuration on the user part. This part will hopefully address the configuration issue and errors that comes from it.
Of course, download of otb through qgis is optional and is not forced on any user.
It was one of the goals to keep this plugin code lean and clean. This means no OTB specific information (platform, version, no.of applications) are included in the plugin source. This single feature will mark new otb-qgis plugin a rewrite of previous plugin code.
We also encourage qgis team to integrate it directly into the processing core (like grass, gdal). However the final decision is upto qgis team on that part. Separated plugin code allows to fix bugs in the plugin without waiting for a qgis or otb release. IMHO, keeping this small part of code into qgis processing is better. But I am not sure about this part until we finish the code.
Risks and benefits
Target qgis version is 3.0. However, last qgis 2.x release Can be tested.
Alternatives for implementations
Who will be developing the proposed changes?
CS will be developing under a CNES contract.
Discussion on qgis mailinglist: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Keeping-OTB-algorithm-in-qgis-processing-td5352056.html