Re: [GRASS-user] [GRASS-dev] Keeping GRASS/OTB/... algorithm in qgis processing

[Stefan Blumentrath]

Hi,

In general I would say that both sides (QGIS – GRASS) benefit from an 
integration like Processing or the GRASS plugin. QGIS gains algorithms, GRASS 
gains user base. And for the future, Rashads and Moritz proposal make indeed a 
lot of sense!

The text descriptor files have been a real pain for maintaining interfaces for 
GRASS integration in Processing as well as the GRASS plugin. In addition, they 
make usage of AddOns practically impossible for most of the QGIS users.

However, for QGIS (and this is true for both integrations), the module UI was 
deliberately simplified by hiding / removing “advanced” option or splitting 
modules into “sub-types”. In addition not all modules could be meaningful added 
to the two QGIS integrations (e.g. temporal modules in Processing). And 
finally, some require extra work on the QGIS side (like r.mapcalc).

So, I would assume that a --qgis-descriptor solution would be most appropriate. 
But that would still require additional work (beyond implementing a parser 
solution) if the principles for the GRASS module UI in QGIS should stay as it 
is, like:

-  Tagging options and flags as advanced or basic/main/common (could be 
an opportunity to consolidate terminology in the module UI in GRASS as well)

-  Deciding which modules to use / exclude from QGIS (and how to mark 
them)

-  …
Maybe also Ondrejs work could be useful here : 
https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI ?

Cheers
Stefan



From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad 
Kanavath
Sent: mandag 5. februar 2018 17.06
To: Moritz Lennert 
Cc: grass-user@lists.osgeo.org; grass-...@lists.osgeo.org; Helmut Kudrnovsky 

Subject: Re: [GRASS-dev] [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis 
processing



On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert 
mailto:mlenn...@club.worldonline.be>> wrote:
On 05/02/18 13:51, Helmut Kudrnovsky wrote:
Von: "Moritz Lennert"
I don't know how difficult it would be to create such algorithm
descriptions automagically.

https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93

AFAIU there are some general python scripts to provide it in processing:

e.g.
python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py

No, this is the provider itself, not a tool to create the descriptions.

and there are a lot of txt files providing the module interface

e.g
python/plugins/processing/algs/grass7/description/r.out.png.txt
r.out.png
Export a GRASS raster map as a non-georeferenced PNG image
Raster (r.*)
QgsProcessingParameterRasterLayer|input|Input raster|None|False
QgsProcessingParameterNumber|compression|Compression level of PNG file (0 = 
none, 1 = fastest, 9 = best)|QgsProcessingParameterNumber.Integer|6|True|0|9

and other files

My question was whether it would be possible to create these description files 
more or less automagically.

I think the python scripts for more complex operations have to be created 
manually.

IIUC (from rapid reading of the threads on the qgis-developer list), Rashad's 
suggestion was to keep the *AlgorithmProvider code in the QGIS code base, but 
to possibly move the creation of the description and script files to a plugin 
managed outside QGIS core, possibly by the respective external software teams.

Yes. your are right on track! the idea is external tools (processing providers) 
manage descriptor files in a format requested by qgis processing.
I see already name-of-grass-module --interface-descriptor which gives an xml 
for GRASS gui.
what qgis want is a csv in a specific format. The contents of qgis descriptor 
seems much less compared to --interface-descriptor.
Correct me if I am wrong, --interface-descriptor is available in all grass 
modules. So maybe a --qgis can do the work.

This has some advantages.
* GRASS developers are free to fix parameter name, parameter description, list 
of modules(add and remove) changes without affecting qgis.
* grass 7.5 has 10 modules and grass 7.9 can have 15 and same QGIS will work.
* QGIS will not need to maintain these files and keep updating/adding new 
modules with their release process. whatever is generated from a grass 
build/install have better integration with qgis
* Finally this descriptors for qgis are generated with a makefile target that 
allows users and packagers to include it.
* QGIS can use multiple version of grass by changing install prefix because 
descriptors are *always* found in a directory relative to install prefix.

QGIS provider will be like:
I picked a descriptor file
parse and make the ui,
take input and execute whatever program the descriptor is to run.

QGIS already manages parsing of parameters and running them. So for providers 
who wish to be integrated in qgis will deal with a descriptor file and things 
go fine.

Having a single interface to launch all or most of toolboxes (willing to 
contribute descriptor with installation) can have same way of execution. At 
that point,

Re: [GRASS-user] R: Downloading 7.2.2 and 7.4.0 with Stand-alone installer

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> 2018-02-05 17:24 GMT+01:00 Aldo CLERICI <

> aldo.clerici@

> >:
>> - The operating system is windows 10
>> - 64 bit
> 
> such error has been reported yesterday by another windows user. There
> is something broken in wingrass74 binaries. I will take a look ASAP
> (now busy unfortunately). @Helmut, do you have any idea what could be
> wrong? I have small tip: I have removed gdal20dll dependency before
> creating binaries for G74. Could someone try to reproduce this error
> and then install in osgeo4w framework gdal20dll package, does it help?

unfortunately I can't reproduce the error at the moment.

in my OSGeo4W environment I have:

gdal110.dll
gdal111.dll
gdal200.dll
gdal201.dll
gdal202.dll

renamed stepwise all dlls; there is only an error by renaming gdal202.dll:

C:\>Traceback (most recent call last):
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\wxgui.py", line 167,
in 
sys.exit(main())
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\wxgui.py", line 154,
in main
app = GMApp(workspaceFile)
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\wxgui.py", line 48,
in __init__
wx.App.__init__(self, False)
  File
"C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py",
line 7981, in __init__
self._BootstrapApp()
  File
"C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py",
line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\wxgui.py", line 99,
in OnInit
from lmgr.frame import GMFrame
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\lmgr\frame.py", line
50, in 
from lmgr.layertree import LayerTree, LMIcons
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\lmgr\layertree.py",
line 38, in 
from mapdisp.frame import MapFrame
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\mapdisp\frame.py",
line 33, in 
from mapdisp.toolbars import MapToolbar, NvizIcons
  File
"C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\mapdisp\toolbars.py", line
22, in 
from nviz.main import haveNviz
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\nviz\main.py", line
24, in 
from nviz import mapwindow
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\nviz\mapwindow.py",
line 42, in 
from nviz.workspace import NvizSettings
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\nviz\workspace.py",
line 23, in 
from nviz import wxnviz
  File "C:\OSGEO4~1\apps\grass\grass-7.4.0\gui\wxpython\nviz\wxnviz.py",
line 45, in 
from grass.lib.raster3d import *
  File
"C:\OSGEO4~1\apps\grass\grass-7.4.0\etc\python\grass\lib\raster3d.py", line
23, in 
_libs["grass_g3d.7.4.0"] = load_library("grass_g3d.7.4.0")
  File
"C:\OSGEO4~1\apps\grass\grass-7.4.0\etc\python\grass\lib\ctypes_loader.py",
line 62, in load_library
return self.load(path)
  File
"C:\OSGEO4~1\apps\grass\grass-7.4.0\etc\python\grass\lib\ctypes_loader.py",
line 240, in load
return _WindowsLibrary(path)
  File
"C:\OSGEO4~1\apps\grass\grass-7.4.0\etc\python\grass\lib\ctypes_loader.py",
line 223, in __init__
self.cdll = ctypes.cdll.LoadLibrary(path)
  File "C:\OSGEO4~1\apps\Python27\lib\ctypes\__init__.py", line 443, in
LoadLibrary
return self._dlltype(name)
  File "C:\OSGEO4~1\apps\Python27\lib\ctypes\__init__.py", line 365, in
__init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 126] Das angegebene Modul wurde nicht gefunden

renaming the other dlls, there is no GUI crash.




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] R: Downloading 7.2.2 and 7.4.0 with Stand-alone installer

[Helmut Kudrnovsky]

Aldo Clerici wrote
> Yes, the startup has problems.
> - The operating system is windows 10
> - 64 bit
> - No addons installed.

have you installed the MS runtimes libraries during installation procedure?

unfortunately I can't reproduce the error.

have you tried OSGeo4W-64bit-winGRASS?



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Keeping GRASS/OTB/... algorithm in qgis processing

[Moritz Lennert]

On 05/02/18 17:06, Rashad Kanavath wrote:



On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert 
mailto:mlenn...@club.worldonline.be>> wrote:


On 05/02/18 13:51, Helmut Kudrnovsky wrote:

Von: "Moritz Lennert"

I don't know how difficult it would be to create such algorithm
descriptions automagically.


https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93



AFAIU there are some general python scripts to provide it in
processing:

e.g.
python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py


No, this is the provider itself, not a tool to create the descriptions.


and there are a lot of txt files providing the module interface

e.g
python/plugins/processing/algs/grass7/description/r.out.png.txt
r.out.png
Export a GRASS raster map as a non-georeferenced PNG image
Raster (r.*)
QgsProcessingParameterRasterLayer|input|Input raster|None|False
QgsProcessingParameterNumber|compression|Compression level of
PNG file (0 = none, 1 = fastest, 9 =
best)|QgsProcessingParameterNumber.Integer|6|True|0|9

and other files


My question was whether it would be possible to create these
description files more or less automagically.

I think the python scripts for more complex operations have to be
created manually.

IIUC (from rapid reading of the threads on the qgis-developer list),
Rashad's suggestion was to keep the *AlgorithmProvider code in the
QGIS code base, but to possibly move the creation of the description
and script files to a plugin managed outside QGIS core, possibly by
the respective external software teams.


Yes. your are right on track! the idea is external tools (processing 
providers) manage descriptor files in a format requested by qgis 
processing.
I see already name-of-grass-module --interface-descriptor which gives an 
xml for GRASS gui.
what qgis want is a csv in a specific format. The contents of qgis 
descriptor seems much less compared to --interface-descriptor.
Correct me if I am wrong, --interface-descriptor is available in all 
grass modules. So maybe a --qgis can do the work.


Yes, this is what I was aiming at.



This has some advantages.
* GRASS developers are free to fix parameter name, parameter 
description, list of modules(add and remove) changes without affecting qgis.
* grass 7.5 has 10 modules and grass 7.9 can have 15 and same QGIS will 
work.
* QGIS will not need to maintain these files and keep updating/adding 
new modules with their release process. whatever is generated from a 
grass build/install have better integration with qgis
* Finally this descriptors for qgis are generated with a makefile target 
that allows users and packagers to include it.
* QGIS can use multiple version of grass by changing install prefix 
because descriptors are *always* found in a directory relative to 
install prefix.


QGIS provider will be like:
I picked a descriptor file
parse and make the ui,
take input and execute whatever program the descriptor is to run.

QGIS already manages parsing of parameters and running them. So for 
providers who wish to be integrated in qgis will deal with a descriptor 
file and things go fine.


Having a single interface to launch all or most of toolboxes (willing to 
contribute descriptor with installation) can have same way of execution. 
At that point, QGIS should consider

adding some generic code in provider and avoid plugins for such toolboxes.


Thanks for the explanation / confirmation, Rashad.

Now, the question is whether this is in line with the ideas of the QGIS 
developers...


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] R: Downloading 7.2.2 and 7.4.0 with Stand-alone installer

[Martin Landa]

Hi,

2018-02-05 17:24 GMT+01:00 Aldo CLERICI :
> - The operating system is windows 10
> - 64 bit

such error has been reported yesterday by another windows user. There
is something broken in wingrass74 binaries. I will take a look ASAP
(now busy unfortunately). @Helmut, do you have any idea what could be
wrong? I have small tip: I have removed gdal20dll dependency before
creating binaries for G74. Could someone try to reproduce this error
and then install in osgeo4w framework gdal20dll package, does it help?

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] R: Downloading 7.2.2 and 7.4.0 with Stand-alone installer

[Aldo CLERICI]

Yes, the startup has problems.
- The operating system is windows 10
- 64 bit
- No addons installed.

The startup runs ok when installing 7.2.0 and previous versions.
Many thanks.
A. Clerici

-Messaggio originale-
Da: grass-user [mailto:grass-user-boun...@lists.osgeo.org] Per conto di Helmut 
Kudrnovsky
Inviato: lunedì 5 febbraio 2018 17:04
A: grass-user@lists.osgeo.org
Oggetto: Re: [GRASS-user] Downloading 7.2.2 and 7.4.0 with Stand-alone installer

Aldo Clerici wrote
> Dear GRASS users,
> i'm having problems in installing  GRASS7.4.0 (and 7.2.2) on Windows 
> 10 by the Stand-along installer (64bit). I had no problem with 7.2.0 
> and previous versions (7.0.5  7.0.4 ...) The output is reported in the 
> attachment.
> Thanks in advance
> Aldo Clerici
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> Grass7.4.0.PNG (77K)
>  0.PNG>

It seems, not installation but startup of winGRASS has problems.

- which operating system? Win 7, 8, 10? 
-32 bit/64 bit?
- do you have addons installed? Try to delete them first and then try to start 
winGRASS again



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Keeping GRASS/OTB/... algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert  wrote:

> On 05/02/18 13:51, Helmut Kudrnovsky wrote:
>
>> Von: "Moritz Lennert"
>>
>>> I don't know how difficult it would be to create such algorithm
>>> descriptions automagically.
>>>
>> https://github.com/qgis/QGIS/search?p=1&q=processing+grass
>> &type=&utf8=%E2%9C%93
>>
>> AFAIU there are some general python scripts to provide it in processing:
>>
>> e.g.
>> python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py
>>
>
> No, this is the provider itself, not a tool to create the descriptions.
>
>
>> and there are a lot of txt files providing the module interface
>>
>> e.g
>> python/plugins/processing/algs/grass7/description/r.out.png.txt
>> r.out.png
>> Export a GRASS raster map as a non-georeferenced PNG image
>> Raster (r.*)
>> QgsProcessingParameterRasterLayer|input|Input raster|None|False
>> QgsProcessingParameterNumber|compression|Compression level of PNG file
>> (0 = none, 1 = fastest, 9 = best)|QgsProcessingParameterNu
>> mber.Integer|6|True|0|9
>>
>> and other files
>>
>>
> My question was whether it would be possible to create these description
> files more or less automagically.
>
> I think the python scripts for more complex operations have to be created
> manually.
>
> IIUC (from rapid reading of the threads on the qgis-developer list),
> Rashad's suggestion was to keep the *AlgorithmProvider code in the QGIS
> code base, but to possibly move the creation of the description and script
> files to a plugin managed outside QGIS core, possibly by the respective
> external software teams.


Yes. your are right on track! the idea is external tools (processing
providers) manage descriptor files in a format requested by qgis
processing.
I see already name-of-grass-module --interface-descriptor which gives an
xml for GRASS gui.
what qgis want is a csv in a specific format. The contents of qgis
descriptor seems much less compared to --interface-descriptor.
Correct me if I am wrong, --interface-descriptor is available in all grass
modules. So maybe a --qgis can do the work.

This has some advantages.
* GRASS developers are free to fix parameter name, parameter description,
list of modules(add and remove) changes without affecting qgis.
* grass 7.5 has 10 modules and grass 7.9 can have 15 and same QGIS will
work.
* QGIS will not need to maintain these files and keep updating/adding new
modules with their release process. whatever is generated from a grass
build/install have better integration with qgis
* Finally this descriptors for qgis are generated with a makefile target
that allows users and packagers to include it.
* QGIS can use multiple version of grass by changing install prefix because
descriptors are *always* found in a directory relative to install prefix.

QGIS provider will be like:
I picked a descriptor file
parse and make the ui,
take input and execute whatever program the descriptor is to run.

QGIS already manages parsing of parameters and running them. So for
providers who wish to be integrated in qgis will deal with a descriptor
file and things go fine.

Having a single interface to launch all or most of toolboxes (willing to
contribute descriptor with installation) can have same way of execution. At
that point, QGIS should consider
adding some generic code in provider and avoid plugins for such toolboxes.



>
> Moritz
>
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Downloading 7.2.2 and 7.4.0 with Stand-alone installer

[Helmut Kudrnovsky]

Aldo Clerici wrote
> Dear GRASS users,
> i'm having problems in installing  GRASS7.4.0 (and 7.2.2) on Windows 10 
> by the Stand-along installer (64bit). I had no problem with 7.2.0 and
> previous versions (7.0.5  7.0.4 ...)
> The output is reported in the attachment.
> Thanks in advance
> Aldo Clerici
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> Grass7.4.0.PNG (77K)
> ;

It seems, not installation but startup of winGRASS has problems.

- which operating system? Win 7, 8, 10? 
-32 bit/64 bit?
- do you have addons installed? Try to delete them first and then try to
start winGRASS again



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Downloading 7.2.2 and 7.4.0 with Stand-alone installer

[Aldo CLERICI]

Dear GRASS users,
i'm having problems in installing  GRASS7.4.0 (and 7.2.2) on Windows 10  by the 
Stand-along installer (64bit). I had no problem with 7.2.0 and previous 
versions (7.0.5  7.0.4 ...)
The output is reported in the attachment.
Thanks in advance
Aldo Clerici
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Moritz Lennert]

On 05/02/18 13:51, Helmut Kudrnovsky wrote:

Von: "Moritz Lennert"

I don't know how difficult it would be to create such algorithm
descriptions automagically.
  
  https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93


AFAIU there are some general python scripts to provide it in processing:

e.g.
python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py


No, this is the provider itself, not a tool to create the descriptions.



and there are a lot of txt files providing the module interface

e.g
python/plugins/processing/algs/grass7/description/r.out.png.txt
r.out.png
Export a GRASS raster map as a non-georeferenced PNG image
Raster (r.*)
QgsProcessingParameterRasterLayer|input|Input raster|None|False
QgsProcessingParameterNumber|compression|Compression level of PNG file (0 = 
none, 1 = fastest, 9 = best)|QgsProcessingParameterNumber.Integer|6|True|0|9

and other files



My question was whether it would be possible to create these description 
files more or less automagically.


I think the python scripts for more complex operations have to be 
created manually.


IIUC (from rapid reading of the threads on the qgis-developer list), 
Rashad's suggestion was to keep the *AlgorithmProvider code in the QGIS 
code base, but to possibly move the creation of the description and 
script files to a plugin managed outside QGIS core, possibly by the 
respective external software teams.


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Helmut Kudrnovsky]

>I don't know how difficult it would be to create such algorithm
>descriptions automagically.
 
 for a better overview:

processing module description:

https://github.com/qgis/QGIS/tree/9fb386ac60f5e3155294b712ed064ad97eba3226/python/plugins/processing/algs/grass7/description

and related python helper scripts for more complex GRASS modules:

https://github.com/qgis/QGIS/tree/9fb386ac60f5e3155294b712ed064ad97eba3226/python/plugins/processing/algs/grass7/ext

Helmut

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Helmut Kudrnovsky]

Von: "Moritz Lennert" 
>I don't know how difficult it would be to create such algorithm
>descriptions automagically.
 
 https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93

AFAIU there are some general python scripts to provide it in processing:

e.g.
python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py

and there are a lot of txt files providing the module interface

e.g
python/plugins/processing/algs/grass7/description/r.out.png.txt
r.out.png
Export a GRASS raster map as a non-georeferenced PNG image
Raster (r.*)
QgsProcessingParameterRasterLayer|input|Input raster|None|False
QgsProcessingParameterNumber|compression|Compression level of PNG file (0 = 
none, 1 = fastest, 9 = best)|QgsProcessingParameterNumber.Integer|6|True|0|9

and other files

kind regards
Helmut

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Moritz Lennert]

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

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

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Helmut Kudrnovsky]

>>contributions of ideas/support/technical solutions/... are very
welcome.
> Thank you Helli. I wonder if this could be suitable for a GSoC project?

definitely; an early enough inter-project communication would help to
prepare such a GSoC idea ...



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Margherita Di Leo]

Il giorno lun 5 feb 2018 alle 12:40 Helmut Kudrnovsky  ha
scritto:

> 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
>  >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.
>

Thank you Helli. I wonder if this could be suitable for a GSoC project?

>
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Margherita Di Leo
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Helmut Kudrnovsky]

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
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.





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user