On 08/02/18 13:43, Rashad Kanavath wrote:
On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya <[email protected]
<mailto:[email protected]>> 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.
Warning: I don't claim any knowledge of the actual QGIS provider code,
but I'm afraid that this is the case for many external SW developers, so
please bear with me and correct me where I'm wrong.
However, I do have the feeling that part of the debate is due to
fuzzyness of the actual subject. AFAIU, there a different issues here,
and only if we clarify what we are talking about exactly, and what the
actual issues are, can we advance. So, here's my understanding:
1) the descriptor files of the different algorithms in external SW
It seems that at least from OTB and GRASS side, willingness has been
signaled to take over the handling of those.
2) the code that allows to launch these algorithms from within QGIS
IIUC this is again subdivided into two parts:
- a generic class within QGIS code for creating a provider
- the specific external SW related instances of these classes
The first part is definitely part of QGIS core.
The current debate (again AFAIU) is mostly about the second part. And
one question linked to this is how much of the handling can be done by
the generic class code, and how much is SW-specific. IOW, would it be
possible to have exactly the same format of descriptor files for all SW,
and a generic API to interpret those, or are the idiosyncrasies of the
different SW such that API and descriptor files will have to be SW
specific ?
A second question is how much within the second part (the SW specific
provider) depends on evolutions of QGIS code, i.e. when QGIS moves from
one version to the next, will the code in this part have to change, or
will it remain stable, and how much depends on evolutions in the
external SW code. If changes in external SW happen more often than it
seems to make sense to keep this part of the code away from QGIS core,
but if changes in QGIS happen more often than the opposite would seem
better.
Another issue is that current expertise on how to code these providers
is within the QGIS development team. If you decide to put these
providers into plugins, _and_ to no longer ensure the maintenance of
these plugins, this would mean that the development teams of the
external SW have to acquire the necessary knowledge. Looking at general
scarcity of human power in all of the teams, I'm not sure this will
happen easily.
Do I understand things correctly ?
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
