wiki:GSoC/2018/IntegrationInQGIS3

Version 9 (modified by wenzeslaus, 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
Community Bonding

  • Introduce myself in dev list, get in contact with my mentors and discuss the design of functions
  • Prepare the wiki page about the project
  • Set up the GitHub repository of the project
  • Set up a developer environment

Ok
Ok
Ok
Ok

May 14 - May 20
Week 1

  • Implement an initial version of Python library for generating UI files used by Processing plugin based on GRASS modules XML description.

Done

May 21 - May 27
Week 2

  • Integration of generated description UI files from initial Python library to Processing plugin in order to generate GUI dialogue for GRASS modules.

In progress

May 28 - June 3
Week 3

  • Split GRASS module parameters in Processing plugin to basic and advanced tabs.

In progress

June 4 - June 10
Week 4

  • Customization of parameter descriptions in order to take care of differences in GRASS and QGIS terminology.

In progress

July 11 - July 15
Evaluation 1

  • Goal: Working Python library generating files which could be used in Processing plugin
  • Mentors evaluate me and I evaluate mentors of official coding period phase.

June 11 - June 17
Week 5

  • Solve how to split GRASS modules for Processing plugin and minimize user confusion.

June 18 - June 24
Week 6

  • Bugfixing, fix problems which appear after integration of Python library in Processing plugin.

June 25 - July 1
Week 7

  • Implement simplified run or --exec method logic in GRASS.

July 2 - July 8
Week 8

  • Research actual processing code and simplified it for using a run method.

July 9 - July 13
Evaluation 2

  • Goal: Release version of the library, implemented run method in GRASS
  • Mentors evaluate me and I evaluate mentors of official coding period phase.

July 9 - July 15
Week 9

  • Integrate GRASS run logic in Processing plugin

July 16 - July 22
Week 10

  • Create documentation related to GRASS Processing plugin integration (generating UI files, GRASS caller, …).
  • Testing implementation.

July 23 - July 29
Week 11

  • Fix bugs and documentation details.

July 30 - August 5
Week 12

  • Prepare for final delivery.

August 6 - August 14
Evaluation 3 (Final)

  • Wrap up my projects and submit the final evaluation of my mentors.

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
Note: See TracWiki for help on using the wiki.