Re: [QGIS-Developer] OTB and QGIS

[Rashad Kanavath]

Hello Matteo,

Yes you can file a request on otb bug tracker. I think maybe there is a fix 
required in OTB. 

If the fix is to be done in packaging. I think someone in otb team can forward 
to debain gis.

https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] OTB and QGIS

[Rashad Kanavath]

-Original Message-
From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Sebastiaan Couwenberg
Sent: vendredi 18 octobre 2019 13:50
To: 'qgis-developer'
Subject: Re: [QGIS-Developer] OTB and QGIS

On 10/18/19 12:33 PM, Rashad Kanavath wrote:
> A simple fix would be to add otb-qgis as a dependency to "otb" package. This 
> must be done in debian package control!
That's not appropriate, though. otb doesn't require otb-qgis to function
correctly. More appropriate would be for python3-qgis-common to suggest
otb-qgis like it does saga.

That's great. Saga and otb are in same bucket as far as qgis is concerned. 

I agree +1

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] OTB and QGIS

[Rashad Kanavath]

-Original Message-
From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of matteo
Sent: vendredi 18 octobre 2019 11:27
To: qgis-developer
Subject: [QGIS-Developer] OTB and QGIS

Hi guys,

I found quite "difficult" to had OTB working within Processing. In Linux
I had to install (OTB of course) and another package (otb-qgis) and then
it appears in the Processing providers and seems now working.

This maybe a bug.

Otb-qgis package provides tools to generate descriptor files for otb 
alogirthms. 
OTB processing provider uses this tool only if it cannot find a descriptor file 
which should be in package by default. 

Good news is if there is otb-qgis package installed, it is able to create them 
on the fly and everything works.

A simple fix would be to add otb-qgis as a dependency to "otb" package. This 
must be done in debian package control!


> Are there any specific instructions to have it installed, also in Windows 
> environments?

OTB  installation on windows is Download  and extract zip file from 
orfeo-toolbox.org/packages/

6.6.1 is latest https://www.orfeo-toolbox.org/packages/OTB-6.6.1-Win64.zip

You  can simply change location of OTB-X.Y.Z-Linux64 shown in README.md[1]  
with  your OTB windows archive.

Idea:
Add download and extract of OTB into qgis windows installer?. Can be optional 
like GRASS. So windows users won't have to go through any stuff.


> If yes, could it be a good idea to add these instructions in the 
> documentation?

Do you mean in qgis documentation ?

Configuration instructions are detailed in README.md[1]. Maybe this could show 
as help dialog in qgis ?

Not just for OTB, other providers can benefit from it.

https://gitlab.orfeo-toolbox.org/orfeotoolbox/qgis-otb-plugin/blob/master/README.md#open-processing-settings


Cheers and thanks

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] MacOS packaging

[Rashad Kanavath]

On Fri, Oct 26, 2018 at 5:26 PM Peter Petrik <
peter.pet...@lutraconsulting.co.uk> wrote:

> Hello,
>
> we have been asked to create standalone QGIS package for MacOS. By
> standalone I mean that there will be a single package (.pkg) file that will
> be extracted to /Application folder and will contain all dependencies
> (GDAL, Python3, PyQT, Qt libraries, ...) and will be working without any
> additional installation steps (similar to any application you install via
> App Store).
>

Hello Peter,

Did you looked into otb packaging scripts[1]. We are providing standalone
binaries linux, windows and osx using them. It is true that python is not
packaged but I don't see this any blocking issue to include python. Incase
of OTB inclusion of python wasn't a requirement or priority for me. You can
rely on osgeo4mac or whatever rather than otb's superbuild setup. Packaging
scripts are mostly cmake and a small percentage of shell scripts.

HTH

[1] https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/tree/develop/Packaging


>
> As there is no such open-sourced solution I could use or enhance, I
> started some prototyping here:
> https://github.com/lutraconsulting/qgis-mac-packager . I hope I can wrap
> the last bits next week and be able to produce QGIS 3.4 release and QGIS
> master nightlies on some Mac Cloud server. I used osgeo4mac homebrew for
> dependencies, since it looks like it is the most maintained package manager
> with osgeo libraries for MacOS. Usage of Conda packages could be better,
> but the number of downloads and the activity in any available repositories
> is not convincing.
>
> The aim is to eventually have QGIS bundled and shipped similar to Linux
> and Windows. Once we finish the work, we will send an email to the PSC and
> see if this is something they'd be happy to bring it under their umbrella.
>
> I am open to any suggestions or cooperation for either packaging or
> distribution. Feel free to
> write me PM or reply here. Thanks
>
> Now its time to celebrate new QGIS release during weekend!
>
> Cheers,
> Peter
>
> Note: CMAKE scripts try to achieve similar tasks (qgis/mac/cmake/*.in).
> But it seems to me that only bundling of Qt libraries is actively
> maintained [QGIS_MACAPP_BUNDLE=1]and bundling of rest of libs (gdal,
> libzip, geos, etc.. ) [QGIS_MACAPP_BUNDLE=2 and 3] is not
> implemented/maintained. Also I am not convinced that CMake scripting
> language is best tool for such task. (due to reconfiguration on change,
> syntax/readability compared to python, tools available for path handling,
> ...)
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] compile error

[Rashad Kanavath]

On Thu, May 10, 2018 at 1:57 PM, Arun Bharathi 
wrote:

> Hi,
>
> I got this error
>
>  "
>
> CMake Error: The following variables are used in this project, but they
> are set to NOTFOUND.
>
> Please set them or make sure they are set and tested correctly in the
> CMake files:
>
>
> SPATIALINDEX_LIBRARY linked by target "qgis_core" in directory
> /QGIS/src/core
>
you don't have spatialindex dev packages installed or cmake cannot find
Open cmake-gui, and to set it manually. I hope with OSGeo4W it is easy to
find all libs

> Configuring incomplete, errors occurred!
> "
> while compiling cmakelist.txt (QGIS version: 3.1.0 Master) in Qt windows.
>
> Any body help me plz!
>
> Thanks and Regards.
> P.Arun Bharathi
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] only read name and group name of processing algorithms during startup

[Rashad Kanavath]

Hello Nyall,


On Tue, Mar 20, 2018 at 10:55 PM, Nyall Dawson <nyall.daw...@gmail.com>
wrote:

> On 19 March 2018 at 18:39, Rashad Kanavath <rashad.kanav...@c-s.fr> wrote:
> > Nyall,
> >
> > could we have defineCharacteristicsFromFile method in
> > QgsProcessingAlgorithm ?.
> > the diff with canExecute is more of a working draft.
>
>
> Hi Rashad,
>
> Can you open a PR? I'm having trouble following the change as the
> whitespace is messed up in the email.
>

Here we go..
https://github.com/qgis/QGIS/pull/6739

>
> Thanks!
> Nyall
>
> >
> >
> >
> > On Thu, Mar 15, 2018 at 03:27:50PM +0100, Rashad Kanavath wrote:
> >> Hello,
> >>
> >> On Wed, Mar 14, 2018 at 4:38 AM, Nyall Dawson <nyall.daw...@gmail.com>
> >> wrote:
> >>
> >> > On 13 March 2018 at 20:56, Rashad Kanavath <rashad.kanav...@c-s.fr>
> wrote:
> >> > > if a provier is enabled then qgis reads all algorithm's during
> >> > > startup. This involves reading descriptor files and doing all
> parsing
> >> > > required to make gui when user actually open algorithm (click on
> >> > > treeitem).
> >> > > So If I have like three provider enabled it takes more time to start
> >> > qgis than
> >> > > usual. Even though, I might open one or two later at some point.
> >> > >
> >> > > It is not necessary here to parse "all" data during startup.  name
> and
> >> > > group name is only needed to fill provider-algorithm tree. This is
> >> > > true for any provider which uses descriptor files (OTB, GRASS, SAGA
> >> > etc..).
> >> >
> >> > Actually it's a bit trickier here -- models make things more complex
> >> > as they self-validate on creation, and need full knowledge of the
> >> > dependent algorithm's parameters and outputs.
> >> >
> >>
> >> Yes. there are different cases like modeler, standard, batch, scripts.
> >> I tried to utilize canExecute() in otb and seems to be working.
> >> You already have a very flexible, strong API in qgis processing such
> >> trickier feature like this one has become too easy!!.
> >>
> >> I had to call alg.canExecute() in two places and that's it.
> >> diff attached below. With this loading time will be hopefully improved
> for
> >> OTB, SAGA, GRASS GIS.
> >>
> >> index f5bdc40dc5..1cca57769a 100644
> >> --- a/python/plugins/processing/modeler/ModelerParametersDialog.py
> >> +++ b/python/plugins/processing/modeler/ModelerParametersDialog.py
> >> @@ -70,6 +70,7 @@ class ModelerParametersDialog(QDialog):
> >>  QDialog.__init__(self)
> >>  self.setModal(True)
> >>  # The algorithm to define in this dialog. It is an instance of
> >> QgsProcessingModelAlgorithm
> >> +alg.canExecute()
> >>  self._alg = alg
> >>  # The model this algorithm is going to be added to
> >>  self.model = model
> >> @@ -80,6 +81,9 @@ class ModelerParametersDialog(QDialog):
> >>  settings = QgsSettings()
> >>  self.restoreGeometry(settings.value("/Processing/
> >> modelParametersDialogGeometry", QByteArray()))
> >>
> >> +def algorithm(self):
> >> +return self._alg
> >> +
> >>  def closeEvent(self, event):
> >>  settings = QgsSettings()
> >>  settings.setValue("/Processing/modelParametersDialogGeometry",
> >> self.saveGeometry())
> >> @@ -242,7 +246,6 @@ class ModelerParametersDialog(QDialog):
> >>  outTypes = []
> >>  elif not isinstance(outTypes, (tuple, list)):
> >>  outTypes = [outTypes]
> >> -
> >>  return self.model.availableSourcesForChild(self.childId,
> >> [p.typeName() for p in paramType if
> >>
> >>  issubclass(p, QgsProcessingParameterDefinition)],
> >> [o.typeName() for o
> in
> >> outTypes if
> >> diff --git a/src/core/processing/models/qgsprocessingmodelchildalgorit
> hm.cpp
> >> b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> >> index f5f8074c88..01906a7f62 100644
> >> --- a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> >> +++ b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> >> @@ -58,7 +58,7 @@ Qgs

Re: [QGIS-Developer] only read name and group name of processing algorithms during startup

[Rashad Kanavath]

Nyall,

could we have defineCharacteristicsFromFile method in
QgsProcessingAlgorithm ?.
the diff with canExecute is more of a working draft.



On Thu, Mar 15, 2018 at 03:27:50PM +0100, Rashad Kanavath wrote:
> Hello,
> 
> On Wed, Mar 14, 2018 at 4:38 AM, Nyall Dawson <nyall.daw...@gmail.com>
> wrote:
> 
> > On 13 March 2018 at 20:56, Rashad Kanavath <rashad.kanav...@c-s.fr> wrote:
> > > if a provier is enabled then qgis reads all algorithm's during
> > > startup. This involves reading descriptor files and doing all parsing
> > > required to make gui when user actually open algorithm (click on
> > > treeitem).
> > > So If I have like three provider enabled it takes more time to start
> > qgis than
> > > usual. Even though, I might open one or two later at some point.
> > >
> > > It is not necessary here to parse "all" data during startup.  name and
> > > group name is only needed to fill provider-algorithm tree. This is
> > > true for any provider which uses descriptor files (OTB, GRASS, SAGA
> > etc..).
> >
> > Actually it's a bit trickier here -- models make things more complex
> > as they self-validate on creation, and need full knowledge of the
> > dependent algorithm's parameters and outputs.
> >
> 
> Yes. there are different cases like modeler, standard, batch, scripts.
> I tried to utilize canExecute() in otb and seems to be working.
> You already have a very flexible, strong API in qgis processing such
> trickier feature like this one has become too easy!!.
> 
> I had to call alg.canExecute() in two places and that's it.
> diff attached below. With this loading time will be hopefully improved for
> OTB, SAGA, GRASS GIS.
> 
> index f5bdc40dc5..1cca57769a 100644
> --- a/python/plugins/processing/modeler/ModelerParametersDialog.py
> +++ b/python/plugins/processing/modeler/ModelerParametersDialog.py
> @@ -70,6 +70,7 @@ class ModelerParametersDialog(QDialog):
>  QDialog.__init__(self)
>  self.setModal(True)
>  # The algorithm to define in this dialog. It is an instance of
> QgsProcessingModelAlgorithm
> +alg.canExecute()
>  self._alg = alg
>  # The model this algorithm is going to be added to
>  self.model = model
> @@ -80,6 +81,9 @@ class ModelerParametersDialog(QDialog):
>  settings = QgsSettings()
>  self.restoreGeometry(settings.value("/Processing/
> modelParametersDialogGeometry", QByteArray()))
> 
> +def algorithm(self):
> +return self._alg
> +
>  def closeEvent(self, event):
>  settings = QgsSettings()
>  settings.setValue("/Processing/modelParametersDialogGeometry",
> self.saveGeometry())
> @@ -242,7 +246,6 @@ class ModelerParametersDialog(QDialog):
>  outTypes = []
>  elif not isinstance(outTypes, (tuple, list)):
>  outTypes = [outTypes]
> -
>  return self.model.availableSourcesForChild(self.childId,
> [p.typeName() for p in paramType if
> 
>  issubclass(p, QgsProcessingParameterDefinition)],
> [o.typeName() for o in
> outTypes if
> diff --git a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> index f5f8074c88..01906a7f62 100644
> --- a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> +++ b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
> @@ -58,7 +58,7 @@ QgsProcessingModelChildAlgorithm &
> QgsProcessingModelChildAlgorithm::operator=( c
> 
>  const QgsProcessingAlgorithm *QgsProcessingModelChildAlgorithm::algorithm()
> const
>  {
> -  return mAlgorithm.get();
> +  return mAlgorithm && mAlgorithm->canExecute() ? mAlgorithm.get():
> nullptr;
>  }
> 
>  void QgsProcessingModelChildAlgorithm::setModelOutputs( const
> QMap<QString, QgsProcessingModelOutput>  )
> 
> test code for otb provider:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/qgis-otb-plugin
> I can add modification to SAGA and GRASS if you are okay to move this to PR.
> 
> 
> > > Issue is more about calling defineDescriptorFile() in Algorithm's
> > > __init__ method. And ofcourse, one cannot avoid init when adding
> > > algorithm and tree need to add an instance of algorithm. what can be
> > > done?
> >
> > What I've been thinking/planning is to take advantage of task manager
> > here. So basically:
> >
> > - on processing startup, there's no providers added
> > - when the qgis interface is fully loaded then we fire up a background
&

Re: [QGIS-Developer] only read name and group name of processing algorithms during startup

[Rashad Kanavath]

Hello,

On Wed, Mar 14, 2018 at 4:38 AM, Nyall Dawson <nyall.daw...@gmail.com>
wrote:

> On 13 March 2018 at 20:56, Rashad Kanavath <rashad.kanav...@c-s.fr> wrote:
> > if a provier is enabled then qgis reads all algorithm's during
> > startup. This involves reading descriptor files and doing all parsing
> > required to make gui when user actually open algorithm (click on
> > treeitem).
> > So If I have like three provider enabled it takes more time to start
> qgis than
> > usual. Even though, I might open one or two later at some point.
> >
> > It is not necessary here to parse "all" data during startup.  name and
> > group name is only needed to fill provider-algorithm tree. This is
> > true for any provider which uses descriptor files (OTB, GRASS, SAGA
> etc..).
>
> Actually it's a bit trickier here -- models make things more complex
> as they self-validate on creation, and need full knowledge of the
> dependent algorithm's parameters and outputs.
>

Yes. there are different cases like modeler, standard, batch, scripts.
I tried to utilize canExecute() in otb and seems to be working.
You already have a very flexible, strong API in qgis processing such
trickier feature like this one has become too easy!!.

I had to call alg.canExecute() in two places and that's it.
diff attached below. With this loading time will be hopefully improved for
OTB, SAGA, GRASS GIS.

index f5bdc40dc5..1cca57769a 100644
--- a/python/plugins/processing/modeler/ModelerParametersDialog.py
+++ b/python/plugins/processing/modeler/ModelerParametersDialog.py
@@ -70,6 +70,7 @@ class ModelerParametersDialog(QDialog):
 QDialog.__init__(self)
 self.setModal(True)
 # The algorithm to define in this dialog. It is an instance of
QgsProcessingModelAlgorithm
+alg.canExecute()
 self._alg = alg
 # The model this algorithm is going to be added to
 self.model = model
@@ -80,6 +81,9 @@ class ModelerParametersDialog(QDialog):
 settings = QgsSettings()
 self.restoreGeometry(settings.value("/Processing/
modelParametersDialogGeometry", QByteArray()))

+def algorithm(self):
+return self._alg
+
 def closeEvent(self, event):
 settings = QgsSettings()
 settings.setValue("/Processing/modelParametersDialogGeometry",
self.saveGeometry())
@@ -242,7 +246,6 @@ class ModelerParametersDialog(QDialog):
 outTypes = []
 elif not isinstance(outTypes, (tuple, list)):
 outTypes = [outTypes]
-
 return self.model.availableSourcesForChild(self.childId,
[p.typeName() for p in paramType if

 issubclass(p, QgsProcessingParameterDefinition)],
[o.typeName() for o in
outTypes if
diff --git a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
index f5f8074c88..01906a7f62 100644
--- a/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
+++ b/src/core/processing/models/qgsprocessingmodelchildalgorithm.cpp
@@ -58,7 +58,7 @@ QgsProcessingModelChildAlgorithm &
QgsProcessingModelChildAlgorithm::operator=( c

 const QgsProcessingAlgorithm *QgsProcessingModelChildAlgorithm::algorithm()
const
 {
-  return mAlgorithm.get();
+  return mAlgorithm && mAlgorithm->canExecute() ? mAlgorithm.get():
nullptr;
 }

 void QgsProcessingModelChildAlgorithm::setModelOutputs( const
QMap<QString, QgsProcessingModelOutput>  )

test code for otb provider:
https://gitlab.orfeo-toolbox.org/orfeotoolbox/qgis-otb-plugin
I can add modification to SAGA and GRASS if you are okay to move this to PR.


> > Issue is more about calling defineDescriptorFile() in Algorithm's
> > __init__ method. And ofcourse, one cannot avoid init when adding
> > algorithm and tree need to add an instance of algorithm. what can be
> > done?
>
> What I've been thinking/planning is to take advantage of task manager
> here. So basically:
>
> - on processing startup, there's no providers added
> - when the qgis interface is fully loaded then we fire up a background
> task which loads the providers, allowing them to fully build their
> available algorithms and parameters without blocking the startup
> - after the task completes, the tree is populated
>

this is still loading all algorithm with parsing but things will be in
background to not block ui for users. correct?
In that case, you could include above diff and then add loading in
background task. IMHO that will be best.


> I'd like to see more plugins take this approach, so that qgis can load
> nice and quick and the slow stuff happens without annoying users...
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.or

[QGIS-Developer] only read name and group name of processing algorithms during startup

[Rashad Kanavath]

if a provier is enabled then qgis reads all algorithm's during
startup. This involves reading descriptor files and doing all parsing
required to make gui when user actually open algorithm (click on
treeitem).
So If I have like three provider enabled it takes more time to start qgis than
usual. Even though, I might open one or two later at some point. 

It is not necessary here to parse "all" data during startup.  name and
group name is only needed to fill provider-algorithm tree. This is
true for any provider which uses descriptor files (OTB, GRASS, SAGA etc..).

Issue is more about calling defineDescriptorFile() in Algorithm's
__init__ method. And ofcourse, one cannot avoid init when adding
algorithm and tree need to add an instance of algorithm. what can be
done?

There is canExecute() method in baseclass that providers can
override. so init method can read first two line or (single line?) to
fill algorithms tree. And canExecute() can do full parsing of
descriptor files.
I had tried this in OTB code and it seems to work!.

I don't know if there is a better way to implement this or it is
intentional to parse all descriptor files of all providers during
every startup.

I appreciate your comments and feedback on this improvement.

https://gitlab.orfeo-toolbox.org/orfeotoolbox/qgis-otb-plugin/blob/master/otb/OTBAlgorithm.py#L48

-- 
Take care,
Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] regarding pull request #6272

[Rashad Kanavath]

On Fri, Mar 02, 2018 at 02:35:29PM +0100, Rashad Kanavath wrote:
> On Wed, Feb 28, 2018 at 8:57 PM, Paolo Cavallini <cavall...@faunalia.it>
> wrote:
>
I had pushed "otb provider" code as plugin. It is not ready for use
yet. But I wish it can clear confusion in this pull request. 

> > Hi all,
> > anyone availble for a review? Can we do something to speed it up?
> > Thanks a lot.
> >
> 
> Nyall did some review and there was one last issue in one of the code
> snippet (not included in this PR)
> I had explained that also in github. and I think its ready to be merged.
> 
> I will sync this PR with master if someone is willing to merge.
> 
> Thanks in advance,
> 
> 
> >
> > Il 23/02/2018 13:51, Rashad Kanavath ha scritto:
> > > Hello all,
> > >
> > > There were some issue in this PR which made me stop on this task. sorry
> > > for trouble and I would like to resume this integration to QGIS.
> > >
> > > most issues raised by core developers has been explained now. I had
> > > provided some code snippets to explain how processing providers can
> > > use this change in their code.
> > >
> > > Could someone check this and let us know status?
> > >
> > > congrats on QGIS3 && thanks in advance,
> > >
> > >
> > > https://github.com/qgis/QGIS/pull/6272
> > >
> >
> >
> > --
> > Paolo Cavallini - www.faunalia.eu
> > QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> > https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> 
> 
> 
> -- 
> Regards,
>Rashad

> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Take care,
Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] How to disable authentication disabled in messagebar

[Rashad Kanavath]

Hello,

How can I disable authentication from qgis during build or runtime?
Whe opening settings -> options -> authentication, I have below message

"Authentication system is DISABLED:
QCA's OpenSSL plugin (qca-openssl) is missing.
"
I also have an "critical" message in messagbar every time qgis is
started. It's a bit of annoying.
I don't have strong preference of setting authentication/security on
my qgis installation. So I would prefer to disable this feature in build.

"Messages[2] Authentication System : DISABLED. Resources authenticating via the 
system can not be accessed"

If one doesn't have qca-openssl or whatever is required to enable
authentication then is nice to have no such error messages. In this
case, qgis is trying to activate feature where user does not have
required dependencies. And user is well aware of it during configure
step

I get below message during cmake configure.:
"
-- QtCore/QCA include/lib variables missing or CMake is cross-compiling,
-- skipping QCA OpenSSL plugin C++ check
"

-- 
Take care,
Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] regarding pull request #6272

[Rashad Kanavath]

On Wed, Feb 28, 2018 at 8:57 PM, Paolo Cavallini <cavall...@faunalia.it>
wrote:

> Hi all,
> anyone availble for a review? Can we do something to speed it up?
> Thanks a lot.
>

Nyall did some review and there was one last issue in one of the code
snippet (not included in this PR)
I had explained that also in github. and I think its ready to be merged.

I will sync this PR with master if someone is willing to merge.

Thanks in advance,


>
> Il 23/02/2018 13:51, Rashad Kanavath ha scritto:
> > Hello all,
> >
> > There were some issue in this PR which made me stop on this task. sorry
> > for trouble and I would like to resume this integration to QGIS.
> >
> > most issues raised by core developers has been explained now. I had
> > provided some code snippets to explain how processing providers can
> > use this change in their code.
> >
> > Could someone check this and let us know status?
> >
> > congrats on QGIS3 && thanks in advance,
> >
> >
> > https://github.com/qgis/QGIS/pull/6272
> >
>
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] regarding pull request #6272

[Rashad Kanavath]

Hello all,

There were some issue in this PR which made me stop on this task. sorry
for trouble and I would like to resume this integration to QGIS.

most issues raised by core developers has been explained now. I had
provided some code snippets to explain how processing providers can
use this change in their code.

Could someone check this and let us know status?

congrats on QGIS3 && thanks in advance,


https://github.com/qgis/QGIS/pull/6272

-- 
Take care,
Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

Hello,

Sorry for the misunderstanding about my last mail, I didn't want to
be disrespectful. I would like to continue the discussion about this
contribution.

We will push this contribution and try to answer to all
questions, comments or issues about it. We will submit with my colleagues in
few days the QEP to have a strong basis for the discussion about this PR.
Thanks for setting up discussion on external providers at QGIS developer 
meeting. 
I had also registered to this discussion in github page.
I hope that we can continue to work together in a constructive spirit on this 
issue.

-- 
Thanks,
Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 5:51 PM, Paolo Cavallini <cavall...@faunalia.it>
wrote:

> Il 08/02/2018 13:43, Rashad Kanavath ha scritto:
>
> > But aside all decision making stuff, can you check what is to be done in
> > this PR?
> > https://github.com/qgis/QGIS/pull/6272
> > It is something worthy a discussion and not a plugin or not. I was
> > asking because QGIS 3 is near and diff is not that big.
> > If there is something extra need to be done to get this merged, I would
> > happy to hear about it.
>
> agreed, this is an important and urgent point.
> please some qgis dev could check this?
> thanks.
>

I am giving up on this contribution as it seems impossible to get small
changes like this.
Thanks for all your time.


> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya  wrote:

>
>
>>
>> OTB's proposed solution was that plugin or provider algorithm if
>> activated can find otb installation. If not found, there is code which will
>> download and install otb packages and configure it for users.
>>
>
> I still don't see why this cannot be done if OTB provider is a separate
> plugin. Users can install a plugin with the provider, and then that
> provider can have the logic to automatically download OTB, install it, or
> do whatever is needed in case OTB is not found already installed.
>
> I think is is good to educate our users a little bit. We are talking about
> people that will be using complex algorithms for performing advanced
> analysis. I guess we can expect that they can install a plugin themselves
> and it is not a traumatic experience for them... Looks like installing a
> separate plugin it's some sort of cruel chinese torture...when it takes
> just 3 mouse clicks.
>
> I agree with Giovanni, there is no need to provide something that has
> everything installed out-of the box. Also, take into account that reading
> the files that contain the algorithm descriptions takes time (plus, there
> might be some additional checks performed when populating the toolbox).
> People not doing analysis should not have to suffer that extra loading
> time...
>

QGIS increases no of algorithms for a provider. It is simple as that. OTB
has less than 80 applications and coming to QGIS, it will be 100 or 150.
(no interest to count them in qgis)
 And OTB was reading descriptor from xml which is going to be now csv like
others.
Given all that info, I won't be surprised if it takes more time in future
because of new algorithms added to providers. If QGIS was reading proper
way or even open to accepting fixes.

The entire proposal/request to put back OTB was that decision was made on
OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix it,
they can't be put back. This single point was fueling this and other
threads.
Also discussion wasn't started with "why no providers are included?". It
was why some of them are removed even if there is an offer to help!

I don't care enough to continue this discussion about plugin or not plugin.

But aside all decision making stuff, can you check what is to be done in
this PR?
https://github.com/qgis/QGIS/pull/6272
It is something worthy a discussion and not a plugin or not. I was asking
because QGIS 3 is near and diff is not that big.
If there is something extra need to be done to get this merged, I would
happy to hear about it.


> About the R plugin not being available now...well, it's in a separate repo
> and can be adapted to QGIS 3, packaged and published. No one has taken care
> of that, it's true, but that only means we have no R support. If the R
> provider was be in core, it would mean that we would have a dead or
> malfunctioning provider being shipped with QGIS. That is a much worse
> option. And I dont see why, if someone is willing to fix that R provider,
> having it in core will make it easier.
>
> Cheers!
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 10:15 AM, Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>

OTB's proposed solution was that plugin or provider algorithm if activated
can find otb installation. If not found, there is code which will download
and install otb packages and configure it for users.


> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri 
> Cc: qgis-developer ;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-...@lists.osgeo.org>; Victor Olaya 
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - from my experience - comprising years of feedbacks from the courses
> > I teach - the most frequently used algs are available within the GDAL
> > and QGIS algs list
> >
> > - a few generic and widely used algs are from GRASS and SAGA. We would
> > miss them - out of the box - but it could also be an opportunity to
> > port them. For examples v.to.points, transects, profiles.
> > Anyway we would have the plugins for GRASS and SAGA, in case...
> >
> > - specific algs are for specialized users. Here I think plugins are
> > best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added
> > to the list, consistently with the others approach.
> >
> > I appreciate a lot the work from Richard, I hope this discussion is
> > not understood as to belittle its effort!
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavallini 
wrote:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
>
> why not granting them write access?
>
That would still need users *waiting* for QGIS release for fix in algo is
what I understood from other parts of discussion.
I don't know what these developers are going to do with a bugfix after a
new release. That's some kind of mystery unsolved to me.
I hope there will be zero bugs after releases.


>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution


> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri  wrote:

> I'm much more in favour for out of core providers, for the same reasons
> reported by Victor. Having only GDAL and QGIS algorithms in core will
> reduce the number of available algorithms out of the box, but:
>
> - from my experience - comprising years of feedbacks from the courses I
> teach - the most frequently used algs are available within the GDAL and
> QGIS algs list
>

Do you have these toolboxes installed during training? OTB, SAGA, GRASS
etc..
OTB is focused on remote sensing. Unless you have a training or course that
area, your statistics on them being not needed is pretty unreliable. Don't
you think?
What QGIS uses to run a classification/segmentation algorithm without OTB
and GRASS GIS.


> - a few generic and widely used algs are from GRASS and SAGA. We would
> miss them - out of the box - but it could also be an opportunity to port
> them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
>
> - specific algs are for specialized users. Here I think plugins are best
> suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
> list, consistently with the others approach.
>
> I appreciate a lot the work from Richard, I hope this discussion is not
> understood as to belittle its effort!
>
> my 2 cents...
> Giovanni
>
> Il 7 feb 2018 18:25, "Paolo Cavallini"  ha scritto:
>
>> Il 07/02/2018 11:18, Victor Olaya ha scritto:
>> > I dont see the advantage in having providers in core.
>>
>> I see the following:
>> * tests (already available in our infrastructure)
>> * translations
>> * more exposure
>> * documentation
>>
>> > And if there is an
>> > advantage, it's clearly not in how easy it is going to be to maintain
>> > the plugin.
>>
>> until now it has been maintained somehow; if more resources are needed,
>> we can find a way
>>
>> > If the people responsible of a given backend (like OTB) are
>> > going to maintain it (which makes sense), why putting it in core where
>> > they don't have write access?
>>
>> why not granting them write access?
>>
>> > Better in a separate repo. Also, they can
>> > release whenever there are changes, without having to wait for a new
>> > release. That way, the plugin will always be in sync with new releases
>> > of the backend app.
>>
>> this is certainly true; AFAICT OTB people has proposed a solution
>>
>> > If we put them in core...why putting only this big ones (which in some
>> > cases require installing external apps manually by the user), and not
>> > put other plugins that exist and contain Processing providers?
>>
>> I'd be in favour of adding anything important for users.
>>
>> Thanks for your thoughts.
>>
>> When in Madeira we can have a discussion about this. It would be good if
>> all interested parties could meet, locally and remotely.
>>
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya <vola...@gmail.com> wrote:

> I dont think that it is possible to make it more generic. It's not only
> descriptors with only outputs and inputs. Each backend app has its own
> logic. GRASS needs outputs to be converted to its own format. SAGA accepts
> only SHP for vector layers and generates its own SDAT format for raster
> outputs. Parameters are also not passed in the same way to all apps. SAGA
> has extent parameters splitted in 4 params with bbox coordinates. Each
> provider has a different way of indicating a boolean value in the console
> call. In short, the logic must be there somehow, specific for the provider,
>

can you confirm that a GRASS input/output parameter can solve their issue?.
Still there is SAGA and other stuff. So generic provider is not something
QGIS team can do. But I would like to know about this on GRASS issue.


> What is the difference between maintaining a set of descriptor files (as
> you propose) and a set of descriptor files + a class extending
> GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
> easier to have a solid provider class for OTB and then do not ever change
> it (assuming OTB syntax will never change), than having a generic provider,
> which looks rather unfeasible.
>
> Still OTB requires some changes in processing plugin to work. the old way
of twisting application only for QGIS must be avoided.
Without such a change there is no long-term existence even as plugin. Or
worse, it exists and will be broken.
QGIS must recognize such a behavior and avoid adding  burden on external
toolboxes' developer teams by asking for splitting applications. Be it OTB,
GRASS, SAGA whatever.

While I was at it, I saw there is less stuff to be managed and can be done
using a customwidgetwrapper for OTB. because a custom widget wrapper works
in a special way only for one provider.
Hence the idea of generic provider came up!.  In  case of GRASS its
input/output parameter, for OTB it is selection list parameter.

Thanks for your valuable feedback on this. I am sure an idea of generic
provider came up sometime during your work on processing plugin.
It tough and need more expert work and safe is to avoid it totally. I agree
on that part.



> As you say, there is the risk for dead code. In that case, i think it is
> much better to have the provider outside of QGIS core, as a plugin. There
> are dozens of dead plugins, and that is not nice, but it's kinda
> acceptable. Having dead code in QGIS it's a much bigger issue, and we must
> avoid that.
>
> Cheers
>
>
>
> 2018-02-07 14:41 GMT+01:00 Rashad Kanavath <mohammedrasha...@gmail.com>:
>
>> Hello victor,
>>
>> Do you see a possibility of a generic processing provider?. One that can
>> read descriptor files and run algorithms!.
>> I see processing as a single plugin (included in QGIS or not). And if it
>> can avoid need to have sub-plugin managed by all those other development
>> team. That's even better!.
>> Whichever toolbox want to be integrated into processing plugin can
>> provide and maintain descriptor files individually. No QGIS developers need
>> to be involved.
>> This way, external toolboxes' team or qgis does not need to maintain/fix
>> qgis--provider-plugin.
>>
>> search -> download -> install plugin will be changed to configure
>> providers install location.
>> If needed QGIS can control list of available providers (just names).
>>
>> External tools' dev team needs to know something such as spec of
>> descriptor files, how to mention name of executable etc.
>> They don't need to know stuff like how qgis run a processing algorithm,
>> and things working of modeler, running with other algorithms.
>>
>> Anyway, this is just an idea and don't know what will be technically
>> challenging issues?
>>
>> The other way of putting processing plugin into core and providers
>> classified as external plugins can avoid maintenance on qgis.
>> But this "strategy" can result in dead code and users complaining on both
>> projects. Because, at some developers cannot manage project release + a
>> plugin for qgis, another plugin for matlab or whatever
>> Putting all stuff in qgis tree and taking no responsibility of providers
>> isn't good either.
>>
>> This way, each team takes part and result in better collaboration and
>> contribution.
>> As time goes, generic descriptor provider gets better and stronger.
>> Toolboxes are free to add, remove, modify their applications and users from
>> both community benefit best of both worlds.
>>
>>
>> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya <vola...@gmail.com> wrote:
>

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

Hello victor,

Do you see a possibility of a generic processing provider?. One that can
read descriptor files and run algorithms!.
I see processing as a single plugin (included in QGIS or not). And if it
can avoid need to have sub-plugin managed by all those other development
team. That's even better!.
Whichever toolbox want to be integrated into processing plugin can provide
and maintain descriptor files individually. No QGIS developers need to be
involved.
This way, external toolboxes' team or qgis does not need to maintain/fix
qgis--provider-plugin.

search -> download -> install plugin will be changed to configure providers
install location.
If needed QGIS can control list of available providers (just names).

External tools' dev team needs to know something such as spec of descriptor
files, how to mention name of executable etc.
They don't need to know stuff like how qgis run a processing algorithm, and
things working of modeler, running with other algorithms.

Anyway, this is just an idea and don't know what will be technically
challenging issues?

The other way of putting processing plugin into core and providers
classified as external plugins can avoid maintenance on qgis.
But this "strategy" can result in dead code and users complaining on both
projects. Because, at some developers cannot manage project release + a
plugin for qgis, another plugin for matlab or whatever
Putting all stuff in qgis tree and taking no responsibility of providers
isn't good either.

This way, each team takes part and result in better collaboration and
contribution.
As time goes, generic descriptor provider gets better and stronger.
Toolboxes are free to add, remove, modify their applications and users from
both community benefit best of both worlds.


On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:

> I dont see the advantage in having providers in core. And if there is an
> advantage, it's clearly not in how easy it is going to be to maintain the
> plugin. If the people responsible of a given backend (like OTB) are going
> to maintain it (which makes sense), why putting it in core where they don't
> have write access? Better in a separate repo. Also, they can release
> whenever there are changes, without having to wait for a new release. That
> way, the plugin will always be in sync with new releases of the backend app.
>
> If we put them in core...why putting only this big ones (which in some
> cases require installing external apps manually by the user), and not put
> other plugins that exist and contain Processing providers?
>
> I thought the idea was to not have core plugins and avoid them if
> possible. I don't see why we have to treat plugins that have Processing
> provider in a different way. Specially considering how easy it is to
> install a plugin in QGIS.
>
> Cheers
>
>
>
> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini :
>
>> Hi all,
>> following the discussion on qgis-dev ML:
>> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
>> it has been proposed to remove all external providers (namely OTB,
>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>> remain as QGIS cannot be built without). This raised a number of
>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>> release, and to open a wider discussions about this, involving all the
>> interested parties, to find an optimal solution.
>> If volunteers outside QGIS core team, ideally from the respective
>> backends, could take the maintenance of these providers, not much would
>> change for the end user. If not, this will mean effectively missing
>> hundreds of algs from QGIS.
>> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
>> as maintainer.
>> QGIS.ORG will seek to support any decision made with funding where
>> possible.
>> Looking forward for your feedback.
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>>
>
>


-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

Hello all,

Here is a PR to allow integration of otb smoothly. tests are all passing,
commits are squashed and ready to review.
https://github.com/qgis/QGIS/pull/6272
I did a small fix to control visibility of parameter from provider.
Addition of specific parameter class for OTB is not included in this PR.

Thanks for feedback

On Mon, Feb 5, 2018 at 12:20 PM, Helmut Kudrnovsky  wrote:

> >Otherwise if we don't care and just want to enable others to have QGIS
> >intgration, they'll have to adopt the plugins.  That might work better if
> there
> >is real interest.  But I think they usally prefer their tools to be used
> in
> >their own environment and don't care that much about whether it works in
> QGIS
>  >providers?  Otherwise I guess they'll sooner or later will die.
>
> quickly screened the GRASS MLs, I can't find any entry that the GRASS
> community was ever asked if there could be e.g. a shared attempt for an
> automatization to create/maintain the plugin code.
>
> Looking at the new OSGeo website:
>
> *Desktop Applications*
>
> -QGIS Desktop
> -GRASS GIS
>
> *Geospatial Libraries*
>
> -Orfeo ToolBox
> -GDAL/OGR
>
> *Meta CRS Initiative*
>
> -PROJ4
>
> Most of the software mentioned in this thread are projects under the common
> umbrella of OSGeo.
>
> An option may be to ask that OSGeo plays a more proactive role in helping
> to
> coordinate and supporting (technically/financally/...) such inter-project
> challenges.
>
> I will forward a short summary of this thread to the GRASS community.
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-
> f4099106.html
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 7:31 AM, Alexander Bruy <alexander.b...@gmail.com>
wrote:

> BTW, there is also another possible issue to consider. Where users
> will report tickets related to OTB algorithms and who will address
> them?


Come on!. Users already reports issue to OTB if that is the problem.
Do you know any bugs fixed in OTB processing by QGIS team?
To be fair, the processing plugin is in qgis.  And no matter how you
explain some users doesn't listen.
Are you saying this as a problem or something plugin would solve?


2018-02-05 5:43 GMT+02:00 Nyall Dawson <nyall.daw...@gmail.com>:
> > On 4 February 2018 at 22:27, Rashad Kanavath <mohammedrasha...@gmail.com>
> wrote:
> >
> >> Well, OTB provider plugin will be able to fetch and install otb
> binaries. So
> >> users installing plugin is the extra step needed.
> >> 1. Install QGIS
> >> 2. install otb provider plugin
> >> 3. select/download && install otb package
> >
> > This sounds great - and all the more reason why (in my opinion)
> > publishing the provider as a separate plugin is appropriate. A lot of
> > users will only have to make a couple of clicks and have a fully
> > functional OTB install and processing provider ready to go.
> >
> > On the other hand, I don't think this approach is suitable at all for
> > a core provider. What would you propose to do for Linux users? OTB may
> > or may not be available in their distro's repos (e.g. it's not
> > available for Fedora), so how would the plugin install the dependency
> > in this case? Or what about for Windows users who do not have
> > administrative rights to install software?
> >
> > I personally don't think there's any way to guarantee that OTB (or
> > SAGA for that matter) is available for all QGIS installs, even if we
> > can manually trigger a download and install via a plugin. And if they
> > aren't, then we make things harder for our users, QGIS trainers and
> > support providers -- the feature set of a standard QGIS install will
> > vary greatly depending on the platform it's installed upon and user's
> > privileges on that platform.
> >
> > Nyall
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alexander Bruy
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 4:43 AM, Nyall Dawson <nyall.daw...@gmail.com> wrote:

> On 4 February 2018 at 22:27, Rashad Kanavath <mohammedrasha...@gmail.com>
> wrote:
>
> > Well, OTB provider plugin will be able to fetch and install otb
> binaries. So
> > users installing plugin is the extra step needed.
> > 1. Install QGIS
> > 2. install otb provider plugin
> > 3. select/download && install otb package
>
> This sounds great - and all the more reason why (in my opinion)
> publishing the provider as a separate plugin is appropriate. A lot of
> users will only have to make a couple of clicks and have a fully
> functional OTB install and processing provider ready to go.
>
> On the other hand, I don't think this approach is suitable at all for
> a core provider. What would you propose to do for Linux users? OTB may
> or may not be available in their distro's repos (e.g. it's not
> available for Fedora), so how would the plugin install the dependency
> in this case? Or what about for Windows users who do not have
> administrative rights to install software?
>

did you checked this package?
https://www.orfeo-toolbox.org//packages/OTB-6.4.0-Linux64.run
and others?
https://www.orfeo-toolbox.org//packages/

We don't need admin rights to install otb. just unzip and it works. Same
for mac and linux.
The dependency is libc and libc++ runtime. And I think any centos6 is our
reference platforms.

Issues you asked is why we introduced binary packages for OTB.


>
> I personally don't think there's any way to guarantee that OTB (or
> SAGA for that matter) is available for all QGIS installs, even if we
> can manually trigger a download and install via a plugin. And if they
> aren't, then we make things harder for our users, QGIS trainers and
> support providers -- the feature set of a standard QGIS install will
> vary greatly depending on the platform it's installed upon and user's
> privileges on that platform.
>
> Nyall
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Sat, Feb 3, 2018 at 5:02 PM, Jürgen E. Fischer  wrote:

> Hi Paolo,
>
> On Thu, 01. Feb 2018 at 11:57:28 +, Paolo Cavallini wrote:
> > Il 01/02/2018 11:51, Alexander Bruy ha scritto:
> > > IMHO, if it is really important for them, they should find a way to
> contact
> > > devs and support development.
>
> > > R provider was removed from core in May 2017 and as far as I can see
> nobody
> > > asked about it in mailing lists. So I suppose it is not important.
>
> > unfortunately users are often silent. but I agree, this is a way of
> > stimulating they reactions.
>
> I guess they'll start complaining once the find that GRASS and SAGA have
> been
> removed from the windows standalone.  Before hardly anyone will notice -
> just
> like nobody noticed that there were more hidden providers, because their
> dependencies were not installed and in turn nobody missed them, when they
> were
> removed again.
>
> The question is who is the driving force behind the provider plugins.  If
> we
> want those algorithms in QGIS, we will probably have to maintain the
> plugins,
> if we don't want them to die.
>
> Otherwise if we don't care and just want to enable others to have QGIS
> intgration, they'll have to adopt the plugins.  That might work better if
> there
> is real interest.  But I think they usally prefer their tools to be used in
> their own environment and don't care that much about whether it works in
> QGIS
> or not.  Is there solid interest of the SAGA or GRASS team to adopt the
> providers?  Otherwise I guess they'll sooner or later will die.
>
> At the very least the packaging in OSGeo4W will have to adapted.  The
> easiest
> way would just to remove the dependencies.  This should also kill the
> current
> problem with the 2GB NSIS limit (GRASS depends on python2, SAGA has
> wxWidgets,
> OTB Qt4).
>

Well, OTB provider plugin will be able to fetch and install otb binaries.
So users installing plugin is the extra step needed.
1. Install QGIS
2. install otb provider plugin
3. select/download && install otb package

If my proposal to keep otb provider in qgis was allowed, then it will be
two simple steps. But I don't see that happening soon.

Anyways, if the provider is a plugin or not, it is important to have api to
show/hide widgets from algorithm dialog.( see my other mail on parameter
groups)


>
> The plugins would be downloaded from within QGIS and instruct the user how
> install the rest of the binaries (eg. from OSGeo4W or other sites (like
> OTB)).
>
> There could also be processing provider plugin packages in OSGeo4W that
> have
> the providers and depend on available binaries there.  Although those
> packages
> would need to be available for all or a selection of qgis packages (qgis,
> qgis-rel-dev, qgis-ltr, qgis-ltr-dev and qgis-dev).
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] show/hide widgets in AlgorithmDialog in qgis processing

[Rashad Kanavath]

see other thread.
https://lists.osgeo.org/pipermail/qgis-developer/2018-February/051797.html

closing discussion here.

On Fri, Feb 2, 2018 at 12:22 AM, Nyall Dawson <nyall.daw...@gmail.com>
wrote:

> On 2 February 2018 at 04:12, Rashad Kanavath <mohammedrasha...@gmail.com>
> wrote:
> > Hello,
> >
> > Is there a way to hide and show parameter widgets in Algorithm dialog?
> > current qgsprocessing from master has a FlagHidden for parameters. but
> this
> > should be done before loading algorithm. Once it's loaded, based on user
> > input (say change of selection in QComboBox) I cannot show or hide
> > parameters again.
>
> Can you elaborate on the use case here?
>
> Nyall
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Fri, Feb 2, 2018 at 12:36 AM, Nyall Dawson <nyall.daw...@gmail.com>
wrote:

> On 1 February 2018 at 20:01, Rashad Kanavath <mohammedrasha...@gmail.com>
> wrote:
> > Hello,
> >
> > Processing plugin allows to integrate other toolboxes. IIUC, this was
> one of
> > the features of it.
> > So when you say integration of so and so toolboxes are total mess, you
> might
> > think back.
>
> I think there's a misunderstanding/language barrier at play here -
> no-one meant that the code is a mess, just that the end result of the
> QGIS team trying to maintain 3rd party providers resulted in an
> inferior experience all round - for users, qgis developers AND the
> underlying library developers (whom I'm sure don't appreciate being
> blamed when a QGIS processing algorithm is mis-using their API).
>
>
Can you elaborate on this QGIS processing algorithm mis-using API ?


> Yes, one of Processing's big strengths is its ability to integrate
> other toolboxes and make 3rd party libraries accessible within the
> QGIS environment and tie them together into models. Another one of
> QGIS' great strengths is its strong plugin ecosystem, which allows
> anyone the ability to create plugins and extend QGIS, and not be tied
> into the core QGIS development practices and release schedules. That's
> why plugin-based providers are the BEST solution in my opinion.
>
> > Nobody had seen new changes to otb algs so all of your comments are on
> old
> > version.  Why so rush?
> > Okay, it easy to reject stating the same reason over and over again. I
> > understand that.
>
> Just to be clear - no-one is commenting on your code quality or
> targeting OTB specifically. It's the question of whether or not
> Processing providers which depend on other libraries should be
> included in the main install or moved to plugins which we are
> debating. So please, don't take any of this as criticism of your code
> or (much appreciated) efforts.
>

I never said you commented on code quality. I said everyone should comment
on new code.
But there are comments and or decisions made on old one  codebase even the
thread started with updating and cleaning up stuff.
And I did said that all your comments about that is valid and reasonable.

Hence, I suggested that to see if all your points to keep providers out
still stands with new code. (not done yet)
For SAGA and others, I cannot speak much because I am not involved in it.
so if it feels like I was targeting OTB, this was not against anything.
But I guess saga or even grass is not planning for similar support for qgis
provider like OTB.
 And maybe this is the case for R and others. So that make sense to remove
it from plugin.

If there is one plugin provider which has mostly code tied to processing
then it will be easy for QGIS.
Consider this, OTB plugin was moved out of qgis some time ago and after
that came a lot of changes to qgis processing.
change of parameter names, moving code to c++ etc.. Now GRASS, SAGA etc got
all these changes because it was in tree.
I understand the idea behind removing otb. If this provider wasn't such a
mess to maintain it would have stayed. Even though it
attains the same complexity level as others. I don't agree that it should
be so complex.

And IMHO, the point being this providers are hard to maintain itself lies
with processing plugin and not individual providers or qgis core.
Be it OTB, GRASS , SAGA or anything.


> > What happens at end, a processing plugin with zero providers?
>
> Far from it. My vision would be:
>
> - core install: only includes the native QGIS providers (c++, Python
> and 3D) and the GDAL/OGR provider (since it's impossible to build QGIS
> without GDAL we can be 100% sure that it's always available wherever
> QGIS is installed). Maybe GRASS provider too, since GRASS is very
> heavily linked into QGIS due to the GRASS provider and c++ GRASS
> plugin.

In case of GDAL, I agree. But I (and many other users) don't have GRASS and
SAGA installed.
So this is some kind of assumption that I cannot fully agree. GRASS
provider still has all of descriptor for grass7 in your tree.
And this was/is the case of OTB for now. New changes will not need a
descriptor file in your tree.
OTB installation will provide a descriptor file in the format needed by
qgis processing!

>

- via QGIS' plugin ecosystem: a whole world of providers ready to
> install for users, including SAGA, OTB, lastools, R, PySAL, etc...
>
>
Yes. most of the concern was more with installation of external tools for
users.
>From this and other threads, keeping processing providers outside was not
related to amount or quality code or targetted at specific tool.
Just that it requires external tools. We understand that totally. But what
we don't agree is your assumption that so and so tools is

Re: [QGIS-Developer] update of otb plugin for QGIS

[Rashad Kanavath]

Hello Tisham,

On Fri, Feb 2, 2018 at 3:56 AM, Tisham Dhar <tisham.d...@aerometrex.com.au>
wrote:

> Perhaps the plugin should provide an OTB binaries install mechanism once
> it runs and inspects the platform it is on.
>

Yes. This is my current proposal to otb provider. And the code will be less
and simpler than grass, saga etc..
But unless I finish coding part, It's not easy to have a discussion as
everyone refers to old version all the time.



>
> *From:* Rashad Kanavath [mailto:mohammedrasha...@gmail.com]
> *Sent:* Wednesday, January 31, 2018 7:19 PM
>
> *To:* Tisham Dhar <tisham.d...@aerometrex.com.au>
> *Cc:* qgis-developer@lists.osgeo.org
> *Subject:* Re: [QGIS-Developer] update of otb plugin for QGIS
>
>
>
> Hello,
>
>
>
> On Wed, Jan 31, 2018 at 2:05 AM, Tisham Dhar <
> tisham.d...@aerometrex.com.au> wrote:
>
> Hi Rashad,
>
>
>
> I meant pre-built OTB binaries rather than plugin binaries. I believe QGIS
> builds on more platforms than OTB does.
>
>
>
> plugin code is in python. so nothing much to worry on binaries part and
> they depend on qgis processing code.
>
> QGIS had removed otb plugin from processing and kept others. So there is
> another stuff to work on user side and developer side.
>
>
>
> Regards,
>
>
>
> Tisham.
>
>
>
> *From:* Rashad Kanavath [mailto:mohammedrasha...@gmail.com]
> *Sent:* Tuesday, January 30, 2018 7:45 PM
> *To:* Tisham Dhar <tisham.d...@aerometrex.com.au>
> *Cc:* qgis-developer@lists.osgeo.org
> *Subject:* Re: [QGIS-Developer] update of otb plugin for QGIS
>
>
>
>
>
> Hell Tisham,
>
>
>
> Can you explain the part of binaries issue?
>
>
>
> The documentation of build from source is already there for OTB. The new
> module which if merged into Modules/Wrappers/QGIS will be like any other
> otb module.
>
> Since there are no external dependencies, this could be enabled by
> default. So need to specific documentation to build it is not required.
>
>
>
> But once the coding work is done, there will be another (RFC) and in that
> i will include the usage, builds options etc..
>
>
>
> On Tue, Jan 30, 2018 at 1:10 AM, Tisham Dhar <
> tisham.d...@aerometrex.com.au> wrote:
>
> Hi All,
>
>
>
> I am an avid supporter to OTB and would love to see the plugin brought
> more in line with latest developments in OTB. The binaries issue will
> always exist and I believe OTB should support the same ones for which Qgis
> binaries are available already. The other platforms should have a clear
> build from source documentation. These should be listed in the RFC.
>
>
>
> Regards,
>
>
>
> Tisham Dhar
>
> Research Engineer
>
> Aerometrex PTY LTD
>
> 59 King William St.
>
> Kent Town SA 5067
> <https://maps.google.com/?q=59+King+William+St.%0D+%0D+Kent+Town+SA+5067%0D+Australia=gmail=g>
>
> Australia
> <https://maps.google.com/?q=59+King+William+St.%0D+%0D+Kent+Town+SA+5067%0D+Australia=gmail=g>
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
>
> --
>
> Regards,
>Rashad
>
>
>
>
>
> --
>
> Regards,
>Rashad
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] show/hide widgets in AlgorithmDialog in qgis processing

[Rashad Kanavath]

On Thu, Feb 1, 2018 at 7:32 PM, Alexander Bruy <alexander.b...@gmail.com>
wrote:

> This is not supported. Processing algorithms should have fixed semantic
>

Could we add this support into processing ?



> 2018-02-01 20:12 GMT+02:00 Rashad Kanavath <mohammedrasha...@gmail.com>:
> > Hello,
> >
> > Is there a way to hide and show parameter widgets in Algorithm dialog?
> > current qgsprocessing from master has a FlagHidden for parameters. but
> this
> > should be done before loading algorithm. Once it's loaded, based on user
> > input (say change of selection in QComboBox) I cannot show or hide
> > parameters again.
> >
> > --
> > Regards,
> >Rashad
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alexander Bruy
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] show/hide widgets in AlgorithmDialog in qgis processing

[Rashad Kanavath]

Hello,

Is there a way to hide and show parameter widgets in Algorithm dialog?
current qgsprocessing from master has a FlagHidden for parameters. but this
should be done before loading algorithm. Once it's loaded, based on user
input (say change of selection in QComboBox) I cannot show or hide
parameters again.

-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Thu, Feb 1, 2018 at 11:57 AM, Paolo Cavallini <cavall...@faunalia.it>
wrote:

> Il 01/02/2018 09:35, Rashad Kanavath ha scritto:
> > OTB is not using ogeo4w for a long time. So OSGeo4W users are stuck on
> > old version. We have zero interest in pushing packages back again
> > Windows users can use otb from its binary package, build from source ,
> > or maintain osgeo4w or whatever seems interest.
>
> Thanks Rashad for clarifying. In this case, I'd strongly advise removing
> OTB from osgeo4w ASAP.
> Could you or Julien please do it?
>

I think jef can do this part. I don't have access to repo


> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

practice API
> use for that library.
>
>
> Nyall
>
>
>
> >
> > 2018-01-31 12:17 GMT+02:00 Victor Olaya <vola...@gmail.com>:
> >> The original idea was to have most providers removed...which included
> >> R, GRASS and SAGA as well. Finally, only certain providers were
> >> removed, mostly those that require dependencies not provided with QGIS
> >> (LiDAR tools, R...and OTB)
> >>
> >> If maintaining the plugin is complicated and no work is done on that,
> >> then definitely it is better to keep it as core. But we have to make
> >> sure that the user knows that the provider by itself is useless, and
> >> that OTB has to be installed separately. Otherwise, we will see
> >> confusion and i think it will not be a good idea
> >>
> >> My 2 cents
> >>
> >> 2018-01-31 11:04 GMT+01:00 Paolo Cavallini <cavall...@faunalia.it>:
> >>> Il 31/01/2018 09:50, Rashad Kanavath ha scritto:
> >>>
> >>>> Thanks Paolo,
> >>>> Can you give a link to that discussion?
> >>>
> >>> I had a look to the archives, and I only found this:
> >>> https://lists.osgeo.org/pipermail/qgis-developer/2017-May/048470.html
> >>> Surely Victor and Alex can provide further details.
> >>> All the best.
> >>>
> >>> --
> >>> Paolo Cavallini - www.faunalia.eu
> >>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> >>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> >
> >
> >
> > --
> > Alexander Bruy
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Thu, Feb 1, 2018 at 9:32 AM, Jürgen E. Fischer  wrote:

> Hi Paolo,
>
> On Thu, 01. Feb 2018 at 08:23:30 +, Paolo Cavallini wrote:
> > thanks for your offer, much appreciated. Would this include also the
> > inclusion of OTB in the standalone installers for Windows?
>
> The standalone installers are made from OSGeo4W packages.  So otb should be
> updated there.   IIRC Julien Malik did the last update to 5.2 there.
>

OTB is not using ogeo4w for a long time. So OSGeo4W users are stuck on old
version. We have zero interest in pushing packages back again
Windows users can use otb from its binary package, build from source , or
maintain osgeo4w or whatever seems interest.

>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Wed, Jan 31, 2018 at 11:29 AM, Paolo Cavallini 
wrote:

> Il 31/01/2018 10:26, Alexander Bruy ha scritto:
> > It is included, but this version is really outdated isn't it?
>
> we can seek additional resources to maintain it. Perhaps OTB team is
> interested in maintaining it up to date?
>

the old plugin code had lot of issue like maintain list of supported
version, keeping a backlist and whilelist for supported applications (don't
ask),
splitting of apps because groups aren't supported to name a few.
And I think this one of the blocking point for qgis and also otb. It need
to put a lot of efforts to maintain otb provider and cost is triple
compared to others
 If the plugin code was simply generic, qgis would have done maintain it
like old way. Because you only need to change plugin if there is are API
changes,
or some stuff that is made into processing itself. This one will be easy
because all source is in tree you can find places where it needs to change
like:

-from processing.core.AlgorithmProvider import AlgorithmProvider
+from qgis.core import QgsProcessingProvider

And this are back normal.

What I can propose is to lower the burden on maintenance but the code
should be put back to qgis if possible.
So qgis can focus on issue related only to that and after a while things
will stabilize.

Indeed, if there is something broken in this algo otb team will help fix it.

All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] update of otb plugin for QGIS

[Rashad Kanavath]

On Wed, Jan 31, 2018 at 10:12 AM, Paolo Cavallini <cavall...@faunalia.it>
wrote:

> Hi Rashad,
>
> Il 30/01/2018 09:00, Rashad Kanavath ha scritto:
>
> > Regarding qgis versions, there is nothing much to do if you don't change
> > OTB.
>
> I think I understood better now, thanks. In practice, you
> mean adding to OTB a small package who would act as a wrapper for OTB
> algs withing QGIS? So only OTB-specific stuff, nothing that can be
> generalized to other backend?
>

yes. the wrapper will provide necessary descriptor file for otb application
that qgis processing can use.


> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Wed, Jan 31, 2018 at 10:45 AM, Paolo Cavallini <cavall...@faunalia.it>
wrote:

> Il 31/01/2018 09:40, Rashad Kanavath ha scritto:
>
> > With that change coming, are you folks interested to put back otb algo
> > into processing/algs/otb.?
>
> I am supportive of this, even though I understand the argument that
> brought to the removal.
>

Thanks Paolo,
Can you give a link to that discussion?

All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer




-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

Hello all,

I would like to check the pros and cons of keeping otb in qgis processing
like others.  SAGA, GRASS, GDAL etc..

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?

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)

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.

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.

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...
With that change coming, are you folks interested to put back otb algo into
processing/algs/otb.?

-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] update of otb plugin for QGIS

[Rashad Kanavath]

Hello,

On Wed, Jan 31, 2018 at 2:05 AM, Tisham Dhar <tisham.d...@aerometrex.com.au>
wrote:

> Hi Rashad,
>
>
>
> I meant pre-built OTB binaries rather than plugin binaries. I believe QGIS
> builds on more platforms than OTB does.
>
>
>
plugin code is in python. so nothing much to worry on binaries part and
they depend on qgis processing code.
QGIS had removed otb plugin from processing and kept others. So there is
another stuff to work on user side and developer side.

Regards,
>
>
>
> Tisham.
>
>
>
> *From:* Rashad Kanavath [mailto:mohammedrasha...@gmail.com]
> *Sent:* Tuesday, January 30, 2018 7:45 PM
> *To:* Tisham Dhar <tisham.d...@aerometrex.com.au>
> *Cc:* qgis-developer@lists.osgeo.org
> *Subject:* Re: [QGIS-Developer] update of otb plugin for QGIS
>
>
>
>
>
> Hell Tisham,
>
>
>
> Can you explain the part of binaries issue?
>
>
>
> The documentation of build from source is already there for OTB. The new
> module which if merged into Modules/Wrappers/QGIS will be like any other
> otb module.
>
> Since there are no external dependencies, this could be enabled by
> default. So need to specific documentation to build it is not required.
>
>
>
> But once the coding work is done, there will be another (RFC) and in that
> i will include the usage, builds options etc..
>
>
>
> On Tue, Jan 30, 2018 at 1:10 AM, Tisham Dhar <
> tisham.d...@aerometrex.com.au> wrote:
>
> Hi All,
>
>
>
> I am an avid supporter to OTB and would love to see the plugin brought
> more in line with latest developments in OTB. The binaries issue will
> always exist and I believe OTB should support the same ones for which Qgis
> binaries are available already. The other platforms should have a clear
> build from source documentation. These should be listed in the RFC.
>
>
>
> Regards,
>
>
>
> Tisham Dhar
>
> Research Engineer
>
> Aerometrex PTY LTD
>
> 59 King William St.
>
> Kent Town SA 5067
> <https://maps.google.com/?q=59+King+William+St.%0D+%0D+Kent+Town+SA+5067%0D+Australia=gmail=g>
>
> Australia
> <https://maps.google.com/?q=59+King+William+St.%0D+%0D+Kent+Town+SA+5067%0D+Australia=gmail=g>
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
>
> --
>
> Regards,
>Rashad
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] update of otb plugin for QGIS

[Rashad Kanavath]

Hell Tisham,

Can you explain the part of binaries issue?

The documentation of build from source is already there for OTB. The new
module which if merged into Modules/Wrappers/QGIS will be like any other
otb module.
Since there are no external dependencies, this could be enabled by default.
So need to specific documentation to build it is not required.

But once the coding work is done, there will be another (RFC) and in that i
will include the usage, builds options etc..

On Tue, Jan 30, 2018 at 1:10 AM, Tisham Dhar 
wrote:

> Hi All,
>
>
>
> I am an avid supporter to OTB and would love to see the plugin brought
> more in line with latest developments in OTB. The binaries issue will
> always exist and I believe OTB should support the same ones for which Qgis
> binaries are available already. The other platforms should have a clear
> build from source documentation. These should be listed in the RFC.
>
>
>
> Regards,
>
>
>
> Tisham Dhar
>
> Research Engineer
>
> Aerometrex PTY LTD
>
> 59 King William St.
>
> Kent Town SA 5067
>
> Australia
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] update of otb plugin for QGIS

[Rashad Kanavath]

On Mon, Jan 29, 2018 at 5:36 PM, Paolo Cavallini <cavall...@faunalia.it>
wrote:

> Il 29/01/2018 16:59, Rashad Kanavath ha scritto:
> > (x-post to qgis-developer list)
> >
> > Hello all,
> >
> > Here is an RFComments for new otb plugin.
> > https://gitlab.orfeo-toolbox.org/jmichel/otb/blob/
> 790c2b7a5e3060d4e597d078c3c92e353a102773/.gitlab/issue_
> templates/request_for_comments.md
> >
> > Feel free to send your comments and suggestions
>
> Hi Rashad,
> unclear to me how do you want to manage binaries for the many OS and
> versions QGIS supports.
> Thanks for clarifications.
>

Hello Paolo,

OTB provides a full bundle of all libs, apps and dependencies for three OS
platforms (windows, linux and macos) for every release[1] and every day[2]
These packages are tested on dashboard[3] with list of tests passing.
[1] https://www.orfeo-toolbox.org//packages/
[2] https://www.orfeo-toolbox.org//packages/nightly/latest/
[3] https://dash.orfeo-toolbox.org/index.php?project=OTB

what I was implying was the qgis descriptor files will be included in this
packages for ease install/change of otb versions.

For instance, if you have OTB 6.4 already working with plugin. An update of
otb to 6.8 will be
1. download package
2. update otb install prefix in the plugin configuration. (in sed world
s/6.4/6.8/g :)

Regarding qgis versions, there is nothing much to do if you don't change
OTB.

Hope that helps,


--
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer




-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] update of otb plugin for QGIS

[Rashad Kanavath]

(x-post to qgis-developer list)

Hello all,

Here is an RFComments for new otb plugin.
https://gitlab.orfeo-toolbox.org/jmichel/otb/blob/790c2b7a5e3060d4e597d078c3c92e353a102773/.gitlab/issue_templates/request_for_comments.md

Feel free to send your comments and suggestions

-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer