GRASS GSoC Ideas 2024

From GRASS-Wiki
Revision as of 16:12, 13 May 2024 by Hamed5001 (talk | contribs)
Jump to navigation Jump to search

About

Accepted ideas

Add JSON output to different GRASS tools in C

  • Student: Kriti Birda
  • Mentors: Corey White and Vaclav Petras
  • Wiki page

Add EODAG support to GRASS GIS

  • Student: Hamed Ashraf
  • Mentors: Luca Delucchi, Veronica Andreo, Stefan Blumentrath
  • [GRASS_GSoC_2024_EODAG_Support|Wiki page]

Parallelization of existing tools in GRASS GIS

  • Student: Chung-Yuan Liang
  • Mentors: Huidae Cho, Vaclav Petras, Maris Nartiss
  • Wiki page

Improve GRASS user experience in Jupyter Notebook

  • Student: Riya Saxena
  • Mentors: Anna Petrasova, Corey White
  • Wiki page

Ideas

If you are a student you can suggest a new idea or pick up an existing one. In any case write about it to grass-dev mailing list,GitHub Discussions, or Gitter.

You are invited as well to have a close look at ideas from previous years (2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023) which have not yet been implemented. You can also look at accepted GRASS 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.


Parallelization of existing tools

There are several tools that would benefit from parallelization with OpenMP, e.g. r.texture, r.horizon, r.fill.stats, r/v.surf.idw, r.viewshed, v.to.rast, r.grow.distance, v.surf.bspline, ... For overview of current state, see Raster_Parallelization_with_OpenMP.

  • Requirements: familiarity with C, OpenMP
  • Mentor: Huidae Cho
  • Co-mentor: Vaclav Petras, Anna Petrasova
  • Project length: 175 or 350 hours (take your pick)
  • Rating: medium
  • Expected Outcomes: parallelized module or modules, depending on complexity
  • Test of skills: suggest/implement solution for https://github.com/OSGeo/grass/issues/2644

Improve GRASS user experience in Jupyter Notebook

InteractiveMap in grass.jupyter library

Python package grass.jupyter was developed during GSoC 2021 to simplify running GRASS from Jupyter Notebooks and displaying data. This project could focus on adding features such as adding parallelization for rendering, increasing interactivity of displayed data using ipyleaflet (e.g., capture mouse clicks to show information about vector line, pixel), adding API for managing projects and subprojects (i.e., locations/mapsets), simplifing display of attribute data, ...

  • Requirements: Python
  • Mentor: Anna Petrasova
  • Co-mentor: Vaclav Petras, Helena Mitasova
  • Project length: 175 or 350 hours (take your pick)
  • Rating: easy to medium
  • Expected Outcomes: improved user experience when using GRASS through notebooks
  • Test of skills: https://github.com/OSGeo/grass/issues/3276, or write a test for grass.jupyter library using python unittest or pytest, more info here.

Add JSON output to different tools in C

There are several tools in GRASS that would benefit from a JSON-formatted output, see this issue for a list of tools. Besides adding the JSON output, the work would also include adding tests and basic documentation.

  • Requirements: C, Python for tests
  • Mentor: Vaclav Petras
  • Co-mentor: Anna Petrasova, Corey White
  • Project length: 175 or 350 hours (take your pick)
  • Rating: easy to medium
  • Expected Outcomes: one or more (depending on project length and complexity of the tool) tools with well tested JSON output
  • Test of skills: Address https://github.com/OSGeo/grass/issues/1044 for r.surf.fractal

Support writing tests with pytest

  • 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.
  • 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.
  • Using pytest should lead to tests which feel more like Python scripts and to minimum of testing-specific code.
  • 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).
  • Two main things needed:
    • Create general comparison functions from the grass.gunittest assert methods so that they can be used with pytest.
    • 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
  • Additional things needed:
    • Fixture for pytest to set up and tear down a GRASS session in a temporary mapset.
  • Requirements: Python
  • Project length: 175 or 350 hours (take your pick)
  • Mentor: Vaclav Petras
  • Co-mentor: Stefan Blumentrath
  • Proposed by: Vaclav Petras
  • Rating: easy to medium
  • Expected Outcomes: Convenient way of writing tests with pytest
  • 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.

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
  • Project length: 350 hours
  • Rating: medium
  • 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: Stefan Blumentrath
  • Proposed by: Vaclav Petras
  • Expected outcomes: New subcommand which easily runs a GRASS module on GeoTiff and GeoPackage.
  • 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).

STAC (SpatioTemporal Asset Catalog) Integration

Create new import and export capabilities for GRASS GIS which allow users to easily ingest data from STAC catalogs and export locations and mapsets as STAC specs for data discovery within STAC browsers.

Add EODAG support to GRASS GIS

EODAG is a Python library useful to download several satellite datasets from different providers (i.e., USGS, Copernicus, AWS, Planetary Computer, etc.). GRASS has various modules to download satellite data like i.sentinel.download, i.landsat.download, i.modis.download. However, they all use different libraries, some of them no longer maintained. Hence, implementing the use of EODAG as back-end for those tools would be very useful not only in terms of maintenance but also in terms of less code repetition. It would also open the possibility for new tools or a master tool to download other datasets directly from GRASS.

  • Requirements: familiar with Python
  • Project length: 175 or 350 hours
  • Mentor: Luca Delucchi
  • Co-mentor: Veronica Andreo
  • Proposed by: Luca Delucchi
  • Rating: medium
  • Expected Outcomes: 175 hours EODAG core library to be able to download products; 350 library + application at least to i.sentinel.download but hopefully also to i.landsat.download
  • Test of skills: https://github.com/OSGeo/grass-addons/issues/1033

GUI: Add space-time datasets support in Data Catalog

Data catalog

Currently GRASS Data Catalog shows only raster and vector maps. The goal of this project is to add support for space-time datasets. It is mainly space-time raster datasets. In the next phase of the project support for other types of space-time datasets (vector and 3D raster) could be added. Besides displaying space-time datasets in the layer tree, it is also about adding the equivalent functionality currently available for raster and vector layers from the context menu.

  • Requirements: familiar with Python
  • Project length: 175 or 350 hours
  • Mentor: Martin Landa
  • Co-mentor: Anna Petrasova
  • Proposed by: Martin Landa
  • Rating: medium
  • Expected Outcomes: 175 hours basic support for space-time raster datasets; 350 extended support also for other space-time datasets types (vector, 3D raster)
  • Test of skills:

Add {your research idea} to GRASS GIS

  • In general, you can propose any topic, but you can specifically propose integrating your research or research idea into GRASS GIS.
  • Requirements:
    • Language:
      • Depends on the project, often Python, sometimes C.
      • Adding your latest ecological analysis
    • Proposal:
      • Discuss relevance to GRASS GIS.
      • Describe technical steps needed for integration.
      • 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.
      • Specify what research was done and what needs to be accomplished in order to have usable product at the end of summer.
      • Specify who will provide the research expertise.
  • Project length: 175 or 350 hours (take your pick)
  • Rating: from low to hard
  • Mentors:
    • 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.
    • Possible technical mentors: Vaclav Petras, Anna Petrasova
    • Research mentors: Bring in an expert from your field, e.g., your academic advisor or project principal investigator (if needed).
  • Proposed by: Vaclav Petras
  • Expected outcome: Working feature which is integrated and merged at the end of the project.
  • Test and training tasks:
    • Create a test in Python for an existing tool in the grass-addons repository or in the core grass repository.

Title of idea

Description here

  • Requirements:
  • Project length: (175 or 350 hours)
  • Mentor:
  • Proposed by:
  • Rating:
  • Expected Outcomes:
  • Test of skills:
  • Other:

Tips for students

  • If you have your own ideas we encourage you to propose them. Explain them on the grass-dev mailing list.
  • If you like some idea here or from previous yeas, write about it on 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 from source and prepare environment for development:
  • Prove your worth by being active on the GRASS mailing lists (grass-user, grass-dev) or other channels (GitHub Discussions, Gitter), fix some 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 OSGeo Foundation's GSoC program umbrella. See the official OSGeo template for application details and other important information at the OSGeo Recommendations for Students.
Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=GRASS_GSoC_Ideas_2024&oldid=27547"