Changes between Initial Version and Version 1 of GSoC/2023


Ignore:
Timestamp:
Jan 23, 2023, 8:36:07 PM (18 months ago)
Author:
annakrat
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2023

    v1 v1  
     1
     2{{{
     3#!html
     4<!-- direct usage of HTML enables to use the big @ characters at the same line as images -->
     5<!-- derived from the HTML taken from GRASS User Mediawiki -->
     6<!-- needs to be changed every year (GSoC link and maybe picture) -->
     7<!-- also check and update links at the bottom -->
     8<p>
     9<a href="https://grass.osgeo.org" rel="nofollow">
     10<img alt="Grasslogo vector small.png" src="/grass/raw-attachment/wiki/GSoC/2014/Grasslogo_vector_small.png" width="110" height="123" />
     11</a>
     12 <font size="+3"> @ </font>
     13<a href="https://summerofcode.withgoogle.com/" rel="nofollow">
     14<img alt="500px-GSoC2016Logo.jpg​" src="/grass/raw-attachment/wiki/GSoC/2016/500px-GSoC2016Logo.jpg"/>
     15</a>
     16<font size="+3"> @ </font>
     17<a href="https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2023" rel="nofollow">
     18<img alt="OSGeo logo" src="/grass/raw-attachment/wiki/GSoC/2018/osgeo_logo.png" width="300" height="97" /></a>
     19</p>
     20}}}
     21
     22
     23= GRASS Google Summer of Code 2023 =
     24
     25[[TOC]]
     26
     27
     28== About ==
     29
     30 * [https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2023 The OSGeo GSoC 2023 main page]
     31 * [https://summerofcode.withgoogle.com/ Official GSoC page at Google]
     32
     33== Ideas ==
     34
     35''Post your ideas here or to the [https://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list], [https://github.com/OSGeo/grass/discussions GitHub Discussions], or [https://gitter.im/grassgis/community Gitter] 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.''
     36
     37If 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],[https://github.com/OSGeo/grass/discussions GitHub Discussions], or [https://gitter.im/grassgis/community Gitter].
     38
     39''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],
     40[https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2009#Ideas 2009], [https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2010#Ideas 2010],
     41[https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2011#Ideas 2011], [https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012#Ideas 2012],
     42[https://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Ideas 2013], [wiki:/GSoC/2014 2014], [wiki:/GSoC/2015 2015], [wiki:/GSoC/2016 2016],
     43[wiki:/GSoC/2017 2017],
     44[wiki:/GSoC/2018 2018],
     45[wiki:/GSoC/2019 2019],
     46[wiki:/GSoC/2020 2020],
     47[wiki:/GSoC/2021 2021],
     48[wiki:/GSoC/2022 2022])
     49which have not yet been implemented.
     50You can also look at accepted GRASS GSoC [wiki:GSoC projects from previous years] for an idea of scope.''
     51
     52''Include "GRASS GIS" in the title of our idea to easily distinguish ideas and projects inside OSGeo.''
     53
     54<!--
     55''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/2023/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2023/CoolGRASSProject`).''
     56-->
     57
     58
     59
     60=== Title of idea ===
     61
     62Description here
     63
     64* Requirements:
     65* Project length: (175 or 350 hours)
     66* Mentor:
     67* Proposed by:
     68* Rating:
     69* Expected Outcomes: 
     70* Test of skills:
     71* Other:
     72
     73
     74=== Parallelization of existing modules ===
     75
     76There are several modules that would benefit from parallelization with OpenMP, e.g. r.texture, r.fill.stats, r/v.surf.idw, r.viewshed, v.to.rast, r.grow.distance,...
     77For overview of current state, see https://grasswiki.osgeo.org/wiki/Raster_Parallelization_with_OpenMP.
     78
     79* Requirements: familiarity with C, OpenMP
     80* Mentor: Huidae Cho
     81* Co-mentor: Vaclav Petras, Anna Petrasova
     82* Project length: 175 or 350 hours (take your pick)
     83* Rating: medium
     84* Expected Outcomes: parallelized module or modules, depending on complexity
     85* Test of skills: https://github.com/OSGeo/grass/issues/2118
     86
     87=== Improve GRASS user experience in Jupyter Notebook ===
     88Python package grass.jupyter was developed during [https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS GSoC 2021] to simplify running GRASS from Jupyter Notebooks and displaying data. This project could focus on adding features such as:
     89  * animating series of maps (currently we can animate only temporal datasets)
     90  * add parallelization for rendering
     91  * increase interactivity of displayed data using ipyleaflet, e.g., capture mouse clicks to show information about vector line, pixel
     92  * add API for managing projects and subprojects (i.e., locations/mapsets)
     93  * simplify display of attribute data
     94
     95* Requirements: Python
     96* Mentor: Vaclav Petras
     97* Co-mentor: Anna Petrasova, Helena Mitasova
     98* Project length: 175 or 350 hours (take your pick)
     99* Rating: easy to medium
     100* Expected Outcomes: improved user experience when using GRASS through notebooks
     101* Test of skills: https://github.com/OSGeo/grass/issues/2688, or write a testsuite for a GRASS GIS command, more info [https://grass.osgeo.org/grass-devel/manuals/libpython/gunittest_testing.html here].
     102
     103=== Support writing tests with pytest ===
     104
     105* The current testing framework, ''grass.gunittest'', was written before migration to !Git/GitHub and when long free runs in 3rd party services were unthinkable. Additionally, some no longer relevant goals were prioritized, such as independence on the current code, detailed custom HTML reports, success tracking over time, and high specialization towards GRASS-specifics.
     106* ''grass.gunittest'' is based on Python ''unittest'' package and many projects since then migrated to //pytest//, e.g., GDAL and Numpy. While ''unittest'' is inspired by Java's JUnit, ''pytest'' is designed to support writing small, readable tests, and uses plain `assert` statements instead of many different assert methods.
     107* Using ''pytest'' should lead to tests which feel more like Python scripts and to minimum of testing-specific code.
     108* An example issue of ''grass.gunittest'' is that it doesn't work well with tests of the main GRASS executable (prominence of `grass ... --exec` is yet another new thing which changed since ''grass.gunittest'' was designed).
     109* Two main things needed:
     110  - Create general comparison functions from the ''grass.gunittest'' assert methods so that they can be used with pytest.
     111  - Current grass.script.setup.init function and grass.script.core.create_location function don't work well in the context of a pytest test function. More 
     112* Additional things needed:
     113  - Fixture for pytest to set up and tear down a GRASS session in a temporary mapset.
     114
     115* Requirements: Python
     116* Project length: 175 or 350 hours (take your pick)
     117* Mentor: Vaclav Petras
     118* Co-mentor: Stefan Blumentrath
     119* Proposed by: Vaclav Petras
     120
     121* Rating: easy to medium
     122* Expected Outcomes: Convenient way of writing tests with pytest
     123* 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.
     124
     125=== Improved color management in GRASS GIS ===
     126
     127Current color management of raster and vector maps has several issues:
     128* Interactive editing of colors is rather limited: #3370
     129* 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
     130* [https://trac.osgeo.org/grass/query?status=!closed&keywords=~colors and others...]
     131
     132A 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.
     133
     134* Requirements: Python, wxPython, possibly some C
     135* Project length: 350 hours
     136* Mentor: Anna Petrasova, Vaclav Petras
     137* Co-mentor: Helena Mitasova, Stefan Blumentrath
     138* Proposed by: Anna Petrasova
     139* Rating: medium
     140* Expected Outcomes: More user-friendly color management
     141* Test of skills: [https://trac.osgeo.org/grass/query?status=!closed&keywords=~colors solve one of the color issues]
     142
     143
     144
     145=== New easy-to-use CLI and API for GRASS GIS ===
     146
     147 * Make running of GRASS GIS modules as easy as it is to run GDAL commands.
     148  * `grass run r.slope.aspect elevation=elevation.tiff slope=slope.tiff aspect=aspect.tiff`
     149  * CLI like GDAL has.
     150  * No GRASS Database, Location, Mapset to deal with.
     151  * No import, export from user perspective.
     152  * Reasonable defaults for things like region.
     153  * CLI and API still allows user to specify any of the above.
     154 * Idea page with details: wiki:GSoC/2021/EasyToUseCliAndApiIdea
     155 * Project length: 350 hours
     156 * Rating: medium
     157 * Requirements:
     158  * Language: Python
     159  * 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.
     160 * Mentors: Vaclav Petras
     161 * Co-mentors: Stefan Blumentrath
     162 * Proposed by: Vaclav Petras
     163 * Expected outcomes: New subcommand which easily runs a GRASS module on GeoTiff and GeoPackage.
     164 * Test and training tasks:
     165  * Solve one of the tickets linked at the idea page.
     166  * Add features to `grass` executable interface:
     167   * 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).
     168  * Extend `--exec` functionality:
     169   * Add `--region` to set a temporary computational region for the execution, e.g. `--region="raster=raster_name"`
     170   * Add `--import-raster=some/file.tiff` which imports (r.import) a raster file (same for vector and similarly for export).
     171   * Add `--link-raster=some/file.tiff` which links (r.external) a raster file (same for vector and similarly for r.external.out).
     172
     173=== Add {your research idea} to GRASS GIS ===
     174
     175 * In general, you can propose any topic, but you can specifically propose integrating your research or research idea into GRASS GIS.
     176 * Requirements:
     177   * Language:
     178     * Depends on the project, often Python, sometimes C.
     179     * Adding your latest ecological analysis
     180   * Proposal:
     181     * Discuss relevance to GRASS GIS.
     182     * Describe technical steps needed for integration.
     183     * Describe whether it is an addition of a tool (module) or a change in one of the libraries. If it is a tool, specify if it should be included in the core grass repository or in grass-addons repository and why.
     184     * Specify what research was done and what needs to be accomplished in order to have usable product at the end of summer.
     185     * Specify who will provide the research expertise.
     186 * Project length: 175 or 350 hours (take your pick)
     187 * Rating: from low to hard
     188 * Mentors:
     189   * GRASS GIS project will provide technical mentors, but it is up to the applicant to ensure the research part is mentored well. An exception may be granted to applicants which can demonstrate that the research is finished or that they have enough expertise themselves.
     190   * Possible technical mentors: Vaclav Petras, Anna Petrasova
     191   * Research mentors: Bring in an expert from your field, e.g., your academic advisor or project principal investigator (if needed).
     192 * Proposed by: Vaclav Petras
     193 * Expected outcome: Working feature which is integrated and merged at the end of the project.
     194 * Test and training tasks:
     195   * Create a test in Python for an existing tool in the grass-addons repository or in the core grass repository.
     196== Tips for students ==
     197
     198 * 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].
     199 * 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.
     200 * Follow some good practices in your ideas and proposals:
     201  * Stress why the project would be useful.
     202  * 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.
     203  * Be specific in the implementation (or at least as specific as you can).
     204  * Explain what the final product will look like and how it will work. You can add drawings or mock-ups.
     205  * Explain how the idea relates to existing GRASS GIS functions, features, and needs.
     206  * 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.
     207 * Compile GRASS GIS 8 from source and prepare environment for development:
     208  * Read [https://github.com/OSGeo/grass/blob/main/CONTRIBUTING.md CONTRIBUTING file] and [https://grasswiki.osgeo.org/wiki/Compile_and_Install compilation instructions].
     209  * If you get stuck with the setup, feel free to consult the [https://lists.osgeo.org/listinfo/grass-user grass-user mailing list].
     210  * Familiarize yourself with wiki:Submitting rules.
     211 * 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]) or other channels ([https://github.com/OSGeo/grass/discussions GitHub Discussions], [https://gitter.im/grassgis/community Gitter]), 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.
     212 * Also note that fixing existing bugs and/or implementing enhancements will be a part of student evaluation.
     213
     214 * 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].