QGIS / OTB integration

#1

Dear all,

I open this discussion feed because we have more and more users who want to use OTB through QGIS 3.x and I think the situation is not very clear.

Here are some suggestions of what we should do to improve the situation :

  • clearly describe which versions of QGIS & OTB can be used together, with the right plugin
    • this could be done in the Cookbook, but the actual page is outdated (the new plugin works with QGIS 3.4)
  • write in the Cookbook how to install OTB plugin in QGIS, for the latest versions of QGIS (2.18 LTR, and the new 3.2.* & 3.4.* versions)
  • distribute a zipfile of the plugin under our website (packages)
    • because I think most of people who want to use OTB through QGIS are not developer and don’t have to clone a git repository to install the plugin

What do you think of this proposal ? Should we open issues on OTB documentation and OTB/QGIS plugin ?

#2

I would recommend to keep instructions on installing and configuring QGIS and its plugins out of OTB CookBook. The main reason (as it is evident) is it becomes out-dated very fast due to changing in qgis/otb versions.

You can list README.md url and a link to QGIS online docs for installing plugin.

You can also keep screens of processing algorithms and probably a processing modeler with grass and gdal and otb (if found appropriate)

  • distribute a zipfile of the plugin under our website (packages)

Yes, this could be put under http://orfeo-toolbox.org/qgis/.
There is an existing plugins.xml which can be updated to include otb plugin.

What do you think of this proposal ? Should we open issues on OTB documentation and OTB/QGIS plugin ?

QGIS have a docs of processing_algs on their user manual.
https://docs.qgis.org/testing/en/docs/user_manual/processing_algs

We should try not to encourage duplicate or incomplete docs and thereby confuse users on both projects.

I would recommend to have offline documentation for an otb algorithms. Online docs are not frequently updated and nobody can ever keep them sync in both projects. QGIS processing should be able to render an rst/html if found locally or simply point to OTB cookbook homepage.

The rst sources can be generated for every otb install and are one cmake install command away from packages.

Benefits for OTB and QGIS

  1. same doc everywhere (CookBook, otbcli, QGIS)
  2. No need to track which version of OTB application help to show.

Benefits for QGIS

  1. No need to maintain docs each and every processing provider.

Lastly, I don’t recommend against having online docs. Just that in this case, offline doc is more approiate and less confusing.

#3

Thank you Rashad for your answer.
I agree that we shall not duplicate documentation, but our new end-users must find quickly the documentation. Maybe we can simplify Cookbook and put a link to the right Readme.MD (or later, to a doc in QGIS ?).

Could you create a zipfile for the plugins (versions 3.2 & 3.4) and put them under http://orfeo-toolbox.org/qgis/ ?

Thank you !

#4

I will update plugins.xml on orfeo-toolbox.org/qgis/

And the quickest way to get docs is to have them under click of help button without opening a link. right?

#5

And the quickest way to get docs is to have them under click of help button without opening a link. right?

Yes, I think so.

Thank you for updating plugins.xml

#6

As promised here is the updated visual readme.

Plugins for 3.2 and 3.4 - 3.8 are uploaded!

Feel free to improve or include this link into cookbook.

I would appreciate if you can test readme and verify installation on windows or osx. This code is same as ongoing pr to qgis. So it is a proirity to find any bugs in this if any…
Maybe a call for testing on otb-users group is needed.