<div dir="ltr">Hello all,<div><br></div><div>I would like to check the pros and cons of keeping otb in qgis processing like others.  SAGA, GRASS, GDAL etc..</div><div><br></div><div>one or only argument, I found interesting is the fixes to otb plugin can be done independent of qgis release and versions. But how does other algorithms won't get this cool feature and only OTB?</div><div><br></div><div>One of the reasons why otb plugin got outdated was the separate maintenance issue. otb team were not involved in maintaining this code (processing/algs/otb) on a regular basis. And I don't think putting work on otb team is interesting here. The plugin code works closely with qgis processing with some specifics for running otb. So someone from otb team needs to track changes in qgis code to keep users from running into problems (installation or running of plugins itself)</div><div><br></div><div>For one thing, this didn't worked out well in the past. All  algorithms now in qgis master is updated for qgis3 except for OTB because it's an external plugin. Well, it not like other plugins it depends on qgis processing plugin. </div><div><br></div><div>And due to this change code got left out by both teams. so the argument that updates are independently managed is easy didn't worked here. the problem is solved by creation of another one.</div><div><br></div><div>The old code has lot of hack among other issues. So fixing that is a priority for otb. By that I mean no specific hacks and easy to maintain like SAGA, GRASS etc... </div><div>With that change coming, are you folks interested to put back otb algo into processing/algs/otb.?<br></div><div><br></div><div>-- <br></div><div><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>