Interesting. Let me bring my relative outsider's and newcomer's view
into this. Although a long time QGIS user, I've never really dug into
the Processing tools.
I'm working on a project, where one part is a plugin - mostly a
relatively simple set of dialogs that integrate with other parts of the
QGIS GUI. In another part of the project I develop datasets - and I've
written some processing tools for that based on GDAL. I just yesterday
cleaned two of them up a bit and put them into github and mentioned that
on gdal-dev (I cc this email to gdal-dev). They're Perl programs that
use also other Perl modules.
My intent is to release the plugin to my end users through a website -
the QGIS plugin system allows one to add new library URLs, so I just
need to write an XML file and put the plugin into a zip and upload that
to our server to release a new version. I can make that into "make dist"
or something. I'd like to keep this separate from the official plugin
repository for separate identity and maybe because the plugin is really
for this specific purpose without wider interest at least for now.
I just studied the Processing tools because it seems that maybe I could
also make my processing tools available for my end users (or at least as
a formal deliverable of our project) that way. There seems to be two
possible approaches: 1) get the tools into QGIS-Processing or 2) make a
distribution and ask the end users to install them and use the "Add
script from file" tool in Processing tools (won't work out of box
because python extension is hard coded there). The tools I've made are
pretty generic but I wrote them as pure CLI tools and the other one I
use for huge rasters so it takes a lot of time why I put them running
into some cloud computers. Anyway I definitely see a benefit in running
them from within QGIS and distributing them to end users - and with an
additional code layer the input and output could be tied to layers in
QGIS and dialog boxes. The same way as GDAL utilities are now usable
from QGIS.
The QGIS Processing tools is already now a huge collection of tools.
Some tools are there and directly usable (GDAL for example since I have
GDAL in my computer), some tools can be downloaded for use, and some
tools require that I install more software into my computer (TauDEM for
example).
I see dangers in that one can easily download code from the web into
his/her computer and execute it easily. This will be an issue at least
with IT support of my end users.
I see the benefit of peer control/help/review over add-ons I develop and
make usable by others in QGIS.
Right now I'm a bit confused and also perhaps awed by the potential of
the QGIS Processing tools.
Cheers,
Ari
08.02.2017, 18:49, Alex M kirjoitti:
On 02/06/2017 01:24 AM, Paolo Cavallini wrote:
Il 06/02/2017 10:21, Victor Olaya ha scritto:
Just let make sure that we have some clear acceptance criteria (algs
with tests, trying to follow some "best practices" and using
Processing methods when possible, etc).
right, what could be the procedure then? whan I see a submitted pluygin
that qualifies for this should I warn you (and Nyall) for analysis
before suggesting it to the dev?
All the best.
I thought that https://github.com/qgis/QGIS-Processing was intended for
these kinds of algorithms. It's centralized, but not core, intended for
pure methods instead of plugins.
Perhaps the confusion is that the Plugins and the Processing add-ons
have 2 different installers, and it's not obvious that both exist?
This seems like the start down the path, where after addition of tests
and code review it might then go to core.
Thanks,
Alex
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
