| Version 9 (modified by , 6 years ago) ( diff ) |
|---|
GSoC 2018 Improve GRASS GIS integration in QGIS 3
| Title: | Improve GRASS GIS integration in QGIS 3 |
| Student Name: | Radek Novotný, Czech Technical University in Prague |
| Organization: | OSGeo - Open Source Geospatial Foundation |
| Mentor Name: | Vaclav Petras, Marin Landa |
| GitHub Repository: | view repository |
| GSoC proposal: | view proposal |
Abstract
Currently, GRASS integration in QGIS is hard to maintain. There are two QGIS plugins - Processing and GRASS Plugin, which differs each other. This proposal is focused on Processing plugin. Processing plugin is at this moment maintained by QGIS developers in core Git repository. This situation has been discussed in the QGIS and GRASS GIS mailing lists several times. GUI dialogues of the Processing plugin are generated from manually maintained text UI description files.
Goal
My goal is to design a Python library (and possibly also a GRASS module based on this library) which allows creating this text UI files automatically from generated GRASS XML description. This library also has to simplify and divide parameters for QGIS. This approach would be similar to the function of SAGA (or OTB) Processing plugin integration QGIS.
After this addition will be possible to generate text UI files for new GRASS modules (added to the core or even for add-ons) in an automated way. These generated UI files can be part of Git repository, but in future could be generated automatically during QGIS compilation, when a user installs GRASS Addon module using Processing plugin, or on the fly when the GUI is started.
Timeline
Time Period | Milestones | |
|---|---|---|
Tasks | Status | |
April 23 - May 14 |
|
Ok |
May 14 - May 20 |
| Done |
May 21 - May 27 |
| In progress |
May 28 - June 3 |
| In progress |
June 4 - June 10 |
| In progress |
July 11 - July 15 |
| |
June 11 - June 17 |
| |
June 18 - June 24 |
| |
June 25 - July 1 |
| |
July 2 - July 8 |
| |
July 9 - July 13 |
| |
July 9 - July 15 |
| |
July 16 - July 22 |
| |
July 23 - July 29 |
| |
July 30 - August 5 |
| |
August 6 - August 14 |
| |
Bonding period report
Introduce myself in dev list, get in contact with my mentors and discuss the design of functions
After being accepted as a student for GSoC 2018, I introduced my self in grass-dev lists on 24th of April (1). Also, I got in contact with my mentors - Marin Landa and Vaclav Petras. I discussed with them how to set-up my dev environment and ask how the functions should be designed.
Prepare the wiki page about the project
I created my project wiki page (2) and added the link to the GSoC 2018 Accepted proposals page (3).
The wiki page includes - General information about the project (title, mentors, links to the proposal and GitHub repository, etc.), a brief description of the project, goal and timeline of tasks and deliverables.
I will keep my wiki page constantly up to date and I’ll add weekly reports following the instructions in the GSoC Recommendations for Student page (4).
Set up the GitHub repository of the project
I chose GitHub (5) as a public repository for the development of this project. I added the link to the GSoC 2018 Accepted proposals page (3), to my wiki page (2) and I shared it with my mentors. My repository is licensed under the GNU General Public License v3.0, according to the licence of GRASS GIS.
Set up a developer environment
I checked and updated my developer environment so as to be ready to start coding after the bonding period.
(1) https://lists.osgeo.org/pipermail/grass-dev/2018-April/088262.html
(2) https://trac.osgeo.org/grass/wiki/GSoC/2018/IntegrationInQGIS3
(3) https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2018_Accepted
(4) https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Students
(5) https://github.com/radeknovotny94/GRASSIntegrationInQGIS3
Weekly reports
Week 1
1) What did I complete this week?
I started work on implementing an initial version of Python library for generating UI files used by Processing plugin based on GRASS modules XML description. Unfortunately, I was not able to finish this task in time, because of I stuck in an automated generation of XML description from GRASS (1). So I have not enough sources for implementation and test of the parser (2).
2) What am I going to achieve for next week?
I want to finish work from the Week 1 and also complete the goal of week 2 - Integration of generated description UI files from initial Python library to Processing plugin in order to generate GUI dialogue for GRASS modules.
3) Is there any blocking issue?
I am blocked with generating XML descriptions from GRASS. (1)
(1) https://github.com/radeknovotny94/GRASS_Parse_to_QGIS_UI/blob/master/generate_batch_for_xml.py
(2) https://github.com/radeknovotny94/GRASS_Parse_to_QGIS_UI/blob/master/GRASSDescribtionParser.py
Week 2
What did you get done this week?
- Implementation of an initial version of the library for parsing description files for QGIS Processing plugin. I solved the problem with creating XML files from week 1. (1)
- Create an independent version of Processing plugin for development. (2)
- Try to create GUI Integration from generated description UI files from initial Python library to Processing plugin.
What do you plan on doing next week?
- Final Python library for parsing descriptions.
- Deep integration of UI descriptions to GUI Processing plugin.
- Split GRASS module parameters in Processing plugin to basic and advanced tabs.
Are you blocked on anything?
No, at the moment I’m not blocked.
(1) https://github.com/radeknovotny94/GRASS_Parse_to_QGIS_UI
(2) https://github.com/radeknovotny94/GRASSIntegrationInQGIS3
Week 3
What did you get done this week?
- I was working on the improvement of the library for parsing description files for QGIS Processing plugin. (1)
- I test creating of GUI from descriptions.
What do you plan on doing next week?
- Final Python library for parsing descriptions.
- Split GRASS module parameters in Processing plugin to basic and advanced tabs.
Are you blocked on anything?
- I have some questions about different ways in QGIS and GRASS, I will discuss them with my mentors.
(1) https://github.com/radeknovotny94/GRASS_Parse_to_QGIS_UI
Week 4
What did you get done this week?
- I finalized the library for parsing description files for QGIS Processing plugin. But of course I suppose, there will occur some bugs, after testing modules in QGIS Processing plugin. (1)
- Add 'Controversy decision' in building parser to wiki. (2)
What do you plan on doing next week?
- Split GRASS module parameters in Processing plugin to basic and advanced tabs - it should be required and optional tab.
- Check GRASS X QGIS parameter descriptions in order to take care of differences in terminology.
Are you blocked on anything?
- No, at the moment I’m not blocked.
(1) https://github.com/radeknovotny94/GRASS_Parse_to_QGIS_UI
(2) https://trac.osgeo.org/grass/wiki/GSoC/2018/IntegrationInQGIS3
Controversial decisions
If 'prompt' is 'raster_3d'
- if this parameter is required - delete description file for QGIS Processing, because Processing does not have 3D Raster class. Could be resolve later.
- if it is optional - pass this parameter
- in both cases is give information about the parameter to log
Examples: Not required parameter: r.colors Not recognized >>> raster_3d
Required parameter: r.to.rast3 Need of 3D raster for module >>> r.to.rast3
If 'prompt' is 'group':
- only in module 'i.group' is parameter 'group' output
- in all other modules should be 'group' input
-if it is in 'r.' module, it is treated like raster multilayer -if it is in 'v.' module, it is treated like vector multilayer
What is treating as the string in QGIS Processing:
- Separators - 'separator' and all names which have not equivalent class in Processing plugin - 'color', 'cats', 'dbname', 'dbtable'.
GRASS GIS layer and sublayer is passed because it is no equivalent in QGIS.
Splitting modules
r.slope.aspect in G vs r.slope, r.aspect, ... in Q
Reasons for splitting:
- Users are used to modules/tools doing one single thing (slope only versus many other things)
- Too many options
