}}}
= GRASS Google Summer of Code 2021 =
[[TOC]]
== About ==
* [https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2021 The OSGeo GSoC 2021 main page]
* [https://summerofcode.withgoogle.com/ Official GSoC page at Google]
== Ideas ==
''Post your ideas here or to the [https://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list] if you want to discuss them more. To edit this wiki, you need to [https://trac.osgeo.org/grass/login login] with an [https://www.osgeo.org/community/getting-started-osgeo/osgeo_userid/ OSGeo Userid]; read also some [wiki:TracLinks help] for using Trac.''
If you are a student you can suggest a new idea or pick up an existing one in any case write about it to [https://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list].
''You are invited as well to have a close look at (and re-suggest!) ideas from previous years ([https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2007 2007], [https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2008#Ideas 2008],
[https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2009#Ideas 2009], [https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2010#Ideas 2010],
[https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2011#Ideas 2011], [https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012#Ideas 2012],
[https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Ideas 2013], [wiki:/GSoC/2014 2014], [wiki:/GSoC/2015 2015], [wiki:/GSoC/2016 2016],
[wiki:/GSoC/2017 2017],
[wiki:/GSoC/2018 2018],
[wiki:/GSoC/2019 2019],
[wiki:/GSoC/2020 2020])
which have not yet been implemented.
You can also look at accepted GRASS GSoC [wiki:GSoC projects from previous years] for an idea of scope.''
''Include "GRASS GIS" in the title of our idea to easily distinguish ideas and projects inside OSGeo.''
''Some bigger ideas may have their own pages, so you can link them here. The pages can be either independent if the page already exists (e.g. `wxGUIDevelopment/SingleWindow`), or more preferably subpages of this page if the idea is (re-)developed for this GSoC. In the later case, use the word "idea" in the page name to distinguish the idea page (e.g. `GSoC/2021/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2021/CoolGRASSProject`).''
=== Title of idea ===
Description here
* Requirements:
* Mentor:
* Proposed by:
* Rating:
* Expected Outcomes:
* Test of skills:
* Other:
=== Parallelization of existing modules ===
There are several modules that would benefit from parallelization with OpenMP, e.g., r.neighbors, r.mfilter, r.univar, r.texture.
For overview of current state, see https://grasswiki.osgeo.org/wiki/OpenMP.
* Requirements: familiarity with C, OpenMP
* Mentor:
* Co-mentor: Anna Petrasova
* Rating: medium
* Expected Outcomes: parallelized module or modules, depending on complexity
* Test of skills: fix https://github.com/OSGeo/grass/issues/1298
=== Seamless integration of GRASS GIS and Jupyter Notebooks ===
* Start of GRASS GIS inside a script or a notebook is currently too cumbersome.
* Maps do not allow panning and other interactions.
* There are [https://grasswiki.osgeo.org/wiki/GRASS_GIS_Jupyter_notebooks examples] how to use Jupyter Notebooks with GRASS GIS, but they need to be improved.
* Requirements: Basic knowledge of GRASS GIS scripting and IPython/Jupyter Notebooks, Python, !JavaScript
* Mentor: Vaclav Petras
* Co-mentor: Helena Mitasova
* Rating: easy
* Expected Outcomes: IPython/Jupyter Notebooks related to grass; some new functions in grass library to show data/tables on IPython/Jupyter Notebooks
* Test of skills: Write a testsuite for a GRASS GIS command, more info [https://grass.osgeo.org/grass-devel/manuals/libpython/gunittest_testing.html here]
=== Integrate testing framework with !GitHub Actions ===
* The testing framework was written before migration to !Git/GitHub and when long free runs in 3rd party services were unthinkable. Additionally, different goals overall were prioritized.
* An update is needed to reflect that tests are used to evaluate pull requests (PRs).
* Most of the updates should be generic enough to integrate well with any CI environment. However, currently GRASS GIS is using !GitHub [https://github.com/OSGeo/grass/actions Actions] which open the possibility to make use of specific features there, e.g., upload artifacts for failed tests or do a quick test only of files changed in the PR.
* Possibly, use //pytest// (following example of GDAL and Numpy) instead of Python unittest (some parts of grass.gunittest might be replaced by or ported to pytest).
* Current tests don't accommodate well tests of the main GRASS executable (which is now more prominent also because `grass ... --exec`).
* Both preserving and removing of existing HTML reporting functionality are valid options.
* Requirements: Python, !GitHub Actions (YAML configuration)
* Mentor: Vaclav Petras
* Proposed by: Vaclav Petras
* Rating: medium
* Expected Outcomes: Effective reporting of test results in pull requests
* Test of skills: Fix failing tests and/or write new tests (more is better). Alternatively, addressing a smaller problem in the testing framework is a good task, too.
=== Improved color management in GRASS GIS ===
Current color management of raster and vector maps has several issues:
* Interactive editing of colors is rather limited: #3370
* We can't easily specify discrete color intervals (e.g. [http://soliton.vm.bytemark.co.uk/pub/cpt-city/cb/seq/tn/BuPu_09.png.index.html this ramp]) for floating point data unless we reclass first, legend does not display that correctly
* [https://trac.osgeo.org/grass/query?status=!closed&keywords=~colors and others...]
A new color editing widget could be developed that would be integrated in r.colors, r3.colors, v.colors, t.rast.colors. It would allow simple editing of breaks (manual and automatic). Better support for discrete color tables for floating point data needs to be developed.
* Requirements: Python, wxPython, possibly some C
* Mentor: Anna Petrasova, Vaclav Petras
* Co-mentor: Helena Mitasova
* Proposed by: Anna Petrasova
* Rating: medium
* Expected Outcomes: More user-friendly color management
* Test of skills: [https://trac.osgeo.org/grass/query?status=!closed&keywords=~colors and others...]
=== Enhance 3D rendering capabilities in GRASS GIS ===
Current 3D rendering capabilities in GRASS GIS (called NVIZ) are quite powerful, but many important features are missing.
The current implementation is rather old and needs to be updated with more recent technologies.
The following points (fixes and new features) should be addressed:
* fix rendering raster and vector data with transparency
* faster rendering of point clouds
* implement text rendering (for scale bars for example)
* review and fix problems with current rendering of 3D vectors
* possible new features would include volume rendering (ray casting for example), so far we can visualize only isosurfaces or slices of 3D rasters
* adding axes
* Requirements: C, OpenGL
* Mentor: Anna Petrasova
* Co-mentor: Vaclav Petras, Helena Mitasova
* Proposed by: Anna Petrasova
* Rating: medium
* Expected Outcomes: reliable on-screen and off-screen 3D rendering on most platforms
* Test of skills: #2076, #3743
=== GRASS GUI: Single window layout ===
Currently, GRASS GIS GUI (wxGUI) has one Layer Manager window and one or more Map Display windows. This multiple window layout can sometimes be problematic and is not common. This project would try to develop an optional single window layout, similarly to [https://docs.gimp.org/2.8/en/gimp-concepts-main-windows.html GIMP]. This project would include:
* detailed design of the behavior of current components + mockups
* refactoring some of the wxGUI components to untangle them and make them reusable
* implementing the actual layout and its behavior while keeping the multiple window layout working
* Requirements: Python, wxPython
* Mentor: Anna Petrasova, Vaclav Petras
* Proposed by: Anna Petrasova
* Rating: medium
* Expected Outcomes: enable switching between single- and multiple-window layout
* Test of skills: Develop a simple wxPython application, which would allow to switch between these two modes. This should demonstrate student knows wxPython and general GUI design.
=== New easy-to-use CLI and API for GRASS GIS ===
* Make running of GRASS GIS modules as easy as it is to run GDAL commands.
* `grass run r.slope.aspect elevation=elevation.tiff slope=slope.tiff aspect=aspect.tiff`
* CLI like GDAL has.
* No GRASS Database, Location, Mapset to deal with.
* No import, export from user perspective.
* Reasonable defaults for things like region.
* CLI and API still allows user to specify any of the above.
* Idea page with details: wiki:GSoC/2021/EasyToUseCliAndApiIdea
* Requirements:
* Language: Python
* Proposal: Student needs to show sufficient understanding of the GRASS GIS Database structure and significantly extend on text below in terms of more concrete formulation of ideas and identification of missing and existing parts.
* Mentors: Vaclav Petras
* Co-mentors:
* Proposed by: Vaclav Petras
* Test and training tasks:
* Solve one of the tickets linked at the idea page.
* Add features to `grass` executable interface:
* Make it possible to associate `*.gxw` files with `grass` executable (#1204) or at least add `--gui-workspace` or preferably just recognize it in the command line (distinguish it from database/location/mapset).
* Extend `--exec` functionality:
* Add `--region` to set a temporary computational region for the execution, e.g. `--region="raster=raster_name"`
* Add `--import-raster=some/file.tiff` which imports (r.import) a raster file (same for vector and similarly for export).
* Add `--link-raster=some/file.tiff` which links (r.external) a raster file (same for vector and similarly for r.external.out).
== Tips for students ==
* If you have your own ideas we encourage you to propose them. Explain them on the [https://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list].
* If you like some idea here or from previous yeas, write about it on [https://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list] and any ideas of your own which could improve it.
* Follow some good practices in your ideas and proposals:
* Stress why the project would be useful.
* Show that you know how you will proceed. That is, make sure that you can demonstrate that the proposal is feasible in the given time frame.
* Be specific in the implementation (or at least as specific as you can).
* Explain what the final product will look like and how it will work. You can add drawings or mock-ups.
* Explain how the idea relates to existing GRASS GIS functions, features, and needs.
* Do not include steps such as "install GRASS", "compile GRASS libraries (on my machine)", "read about the API". You should do this before applying to GSoC.
* Compile GRASS GIS 7 from source and prepare environment for development:
* Read [https://github.com/OSGeo/grass/blob/master/CONTRIBUTING.md CONTRIBUTING file] and [https://grasswiki.osgeo.org/wiki/Compile_and_Install compilation instructions].
* If you get stuck with the setup, feel free to consult the [https://lists.osgeo.org/listinfo/grass-user grass-user mailing list].
* Familiarize yourself with wiki:Submitting rules.
* Prove your worth by being active on the GRASS mailing lists ([https://lists.osgeo.org/listinfo/grass-user grass-user], [https://lists.osgeo.org/listinfo/grass-dev grass-dev]), fix some [https://github.com/OSGeo/grass/issues bugs], and/or implement some (smaller) features, or write some (simpler) GRASS module, and post it to mailing list. There's no better way to demonstrate your willingness and abilities. Do this before start you apply to GSoC.
* Also note that fixing existing bugs and/or implementing enhancements will be a part of student evaluation.
* Every year GRASS GIS hopes to participate and participates in GSoC as part of the [https://www.osgeo.org/ OSGeo Foundation]'s GSoC program umbrella. See the official OSGeo template for application details and other important information at the [https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Students OSGeo Recommendations for Students].
@
@
