On 05/02/18 12:40, Helmut Kudrnovsky wrote:
Dear GRASS GIS community,
herewith I may bring a discussion on QGIS dev ML about how to proceed with
maintaining GRASS, OTB and other algorithms in qgis processing to your
attention.
http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Keeping-OTB-algorithm-in-qgis-processing-td5352056.html
it seems that a shared attempt may be needed for a long-term, sustainable
solution.
citing here my post in that thread:
https://lists.osgeo.org/pipermail/qgis-developer/2018-February/051892.html
---------------------------
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.
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.
--------------------------
contributions of ideas/support/technical solutions/... are very welcome.
The debate is about whether the access to outside tools (i.e. the
'providers') should be kept within the QGIS core code, or whether this
should be externalized to plugins, with the hope that others (the
respective software teams ? users ?) take over the maintenance of these
plugins.
GRASS seems to be seen as something of a border case, also because of
the existing tight (C++ level) linkage between the two through the grass
plugin.
One suggestion coming from Rashad (OTB team) seems to be to leave the
core part of the providers in the QGIS core code (in the idea that that
would ensure that they would be kept up to date together with the core
code), but to leave it up to the respective teams to provide the
algorithm descriptions. But I didn't have the feeling that the QGIS team
was up to that...
I don't know how difficult it would be to create such algorithm
descriptions automagically.
Moritz
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
