}}}
= GRASS Google Summer of Code 2018 =
[[TOC]]
== About ==
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2018 The OSGeo GSoC 2018 main page]
* [https://summerofcode.withgoogle.com/ Official GSoC page at Google]
== Ideas ==
''Post your ideas here or to the [http://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 [http://www.osgeo.org/osgeo_userid OSGeo Userid]; read also some [wiki:TracLinks help] for using trac.''
If you are a student you can suggest an new idea or pick up an existing one in any case write about it to [http://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 ([http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2007 2007], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2008#Ideas 2008],
[http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2009#Ideas 2009], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2010#Ideas 2010],
[http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2011#Ideas 2011], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012#Ideas 2012],
[http://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]) 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/2017/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2017/CoolGRASSProject`).''
=== OSS-Fuzz - Continuous Fuzzing for Open Source Software for GRASS GIS ===
To get rid of cryptic bugs, implement Fuzz testing which is a well-known technique for uncovering various kinds of programming errors in software. Many of these detectable errors (e.g. buffer overflow) can have serious security implications.
Already used in [https://github.com/google/oss-fuzz/tree/master/projects/gdal GDAL fuzz]
* Requirements: C and/or Python
* Mentor: ...
* Rating: medium
* Expected Outcomes: Fuzz testing integrated into GRASS is similar way how GDAL works
* Test of skills: Understand fuzz testing in GDAL
=== Implement a series of image fusion algorithms in GRASS GIS ===
GRASS GIS currently has the G7:i.pansharpen module in core and G7A:i.fusion.hpf as addon. Many other image fusion / pansharpening algorithms exist, and having several of these available in GRASS GIS would be very helpful. These could be implemented as a series of i.fusion.* modules. More background info on practical application can be found at: [http://onlinelibrary.wiley.com/doi/10.1111/2041-210X.12942/full "Schulte to Bühne & Pettorelli 2017"]
Examples of existing fusion algorithms:
* Bayesian fusion algorithms (e.g [http://oatao.univ-toulouse.fr/16629/7/wei_16629.pdf R-FUSE] - see also [https://github.com/qw245/BlindFuse Matlab code])
* [https://arxiv.org/abs/1609.07986 "Super-resolving multiresolution images with band-independant geometry of multispectral pixels"]
* Requirements: C and/or Python
* Mentor: Moritz Lennert
* Rating: medium
* Expected Outcomes:
* Test of skills: finish patch present in #3186 based on comment in ticket, or provide a patch for #3110, #3431 or #2984.
=== 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:
* re-implement off-screen rendering (see m.nviz.image) using current OpenGL technologies (e.g. framebuffers) to work reliably on all platforms/hardware
* 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
* Rating: medium
* Expected Outcomes: reliable on-screen and off-screen 3D rendering on most platforms
* Test of skills: analyze current m.nviz.image code suggest how off-screen rendering could be implemented
=== Additional functionality for running GRASS GIS modules in Jupyter Notebook ===
* Start of GRASS GIS inside a script or a notebook is currently too cumbersome.
* Maps do not allow panning and other interactions.
* Examples how to use Jupyter Notebooks with GRASS GIS are missing. These examples need to be integrated into GRASS GIS, OSGeo (OSGeo-Live) and (interactive) Jupyer documentation.
* Requirements: Basic knowledge of GRASS GIS scripting and IPython/Jupyter Notebooks, Python, !JavaScript
* Mentor: Vaclav Petras
* Co-mentor: Luca Delucchi
* Potential co-mentors: Massimo Di Stefano, Pietro Zambelli
* 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/grass72/manuals/libpython/gunittest_testing.html here]
=== Integration of PDAL into GRASS GIS ===
* Fully replace LibLAS.
* Expose the rich PDAL functionality.
* Share code with modules such as v.in.lidar (libLAS-based) and r.in.xyz for easy future maintenance.
* Optional (depending on time) or as a separate topic: v.external and `@PDAL` pseudo-mapset for point clouds
* Requirements: C, C++
* Mentor: Vaclav Petras
* Co-mentors: Doug Newcomb (non-coding part), Martin Landa
* Accepted: wiki:GSoC/2017/IntegrationOfPDALintoGRASSGIS
* Rating: medium
* Expected Outcomes:
* Test of skills:
=== Benchmarking framework for GRASS GIS ===
* A set of functions/modules to test performance of GRASS GIS modules based on different inputs.
* Examples of such benchmarks.
* Sharing of interface and code with the existing testing framework needs to be addressed.
* See also https://github.com/jachym/grass-performace and wiki:GSoC/2014/TestingFrameworkForGRASS
* Mentor: Vaclav Petras
* Potential co-mentors: Soeren Gebbert, Jachym Cepicky
* Rating: medium
* Expected Outcomes:
* Test of skills:
=== GRASS GIS as a post-processing part of WebODM ===
* Integrate GRASS GIS into WebODM for post-processing of point clouds and orthophotos.
* This will require development in the are of GRASS GIS command line (and/or Python) interface for standalone applications. These improvements need to be integrated into GRASS GIS for maintenance and re-usability purposes.
* Potential mentors: Vaclav Petras, Anna Petrasova
* Rating: medium
* Expected Outcomes:
* Test of skills:
=== Additional GUI tools for image analysis===
GRASS GIS has a series of modules that provide the tools necessary for pixel-based and object-based image analysis. However, some steps in the process still require some rather complicated maneuvers. A series of new GUI modules would be very useful to make the experience more user friendly.
* One task would be the development of GUI modules that allow to attribute class values to either vector polygons or raster areas.
* For the vector case, this would be a generalized GUI to update values in the attribute table without having to enter vector digitizing mode. The module should allow a mechanism of defining the columns that need to be updated to then create a GUI form containing only those columns.
* For the raster case, it would mean a system where the user can click on a raster, get the pixel value and then associate a class value to that pixel value. The result should be written to a text file.
* Another task would be the development of a GUI ruleset generator. Ruleset based classification (object-based or not) means that the user defines a series of rules based on different input bands and pseudo-bands (and for object-based analysis also shape and context indicators). Based on these rules, the system then attributes each pixel/object to a class. Currently this is possible by writing the ruleset as an r.mapcalc input file, using nested if(x,a, b) function calls, or (when vector based) as a series of v.db.update calls. This system quickly gets difficult to read and prone to syntax errors as soon as the number of rules increases. The GUI tool should therefore provide a means to easily select attributes and define rules linked to these attributes. It should then translate these rules to either r.mapcalc calls (raster) or v.db.update calls (vector).
* This project will require the ability to quickly gain working knowledge of the wxPython GUI code base. Examples exist within the existing code to help with this.
* Language requirements: Python, wxPython
* Mentor: Moritz Lennert
* Co-mentor: Vaclav Petras (coding part)
* Co-mentor:
* Rating: medium
* Expected Outcomes:
* Test of skills: solve at least one or two of the issues in #3310
=== Module to create quadtree tiling ===
* Module or set of modules like ''v.mkgrid'' which would generate tiles based on dividing space using the 2D or 3D information of vector features using the quadtree and k-tree (already in the library for working with points).
* This idea needs extending.
* Mentor: ...
* Rating: hard
* Expected Outcomes:
* Test of skills:
=== Tools for generating unit tests from examples in the manual ===
During GSoC 2014 GRASS got a framework for unit test. In order to increase the application of the framework (and thus test coverage) and make it more easily accessible for less experienced developers (e.g. AddOn authors), tools that allow to automatically generate (at least basic) unit tests from examples for module usage in the manual page would be very helpful.
Such tools would also come in handy for adding test coverage for the general functionality of modules which were written before the test framework arrived.
* Language requirements: Python
* Mentor: Vaclav Petras
* Co-mentor: Soeren Gebbert
* Rating: easy
* Expected Outcomes:
* Test of skills:
=== Mapnik rendering engine for GRASS GIS ===
* Mapnik is a powerful rendering engine written in C++ with Python bindings.
* The project tend to add Mapnik engine as alternative backend to [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
* The implementation will have most of the capabilities of actual [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
* The plugin will be able to create different format of images (PNG, PDF, etc)
* The plugin will be able to export XML Mapnik file
* A similar implementation is [https://github.com/springmeyer/quantumnik/ quantumnik]
* Language requirements: Python
* Mentor: Luca Delucchi
* Co-Mentor: Martin Landa
* Rating: medium
* Expected Outcomes:
* Test of skills:
=== Generalized GUI code for Qt-based GUI ===
* wxPython/wxWidgets uses native system libraries for rendering, however there is in fact a lot of platform-dependent behavior and high instability of some features
* Qt is used more and more, QGIS uses Qt
* the current GUI code (wxGUI) often lacks proper design and is hard to maintain, addition of new features requires hacks or refactoring
* a new fresh implementation of GUI is need
* this new implementation should use proper GUI code design so that relevant parts of the code can be used with the new Qt GUI but also with the current wxPython GUI
* this is necessary to avoid duplication of the GUI code and spending the resources on maintaining two code bases (except for the Qt- and wxPython-specific parts)
* this will also show that the logic is actually from the graphical representation
* this avoids dropping wxGUI at the point when the new doesn't have all the features of the new one
* in this was separated parts of the GUI can be implemented in Qt separately
* Mentors: Martin Landa, Anna Petrasova, Vaclav Petras
* Similar project accepted in 2016 (wiki:GSoC/2016/PyQtGUI). This project should move it several steps further.
* Rating: medium
* Expected Outcomes:
* Test of skills:
=== GRASS GIS 3D viewer NVIZ module independent of the main GUI ===
* GRASS GIS 6 has a !Tcl/Tk interface to NVIZ, a GRASS GIS 3D visualization library, and the interface is a standalone application in GRASS GIS environment. This has its disadvantages and thus wxGUI in GRASS GIS 6 and GRASS GIS 7 contains in fully integrated 3D view which is using NVIZ library as a backend. However, this also has its disadvantages and ideal solution is to have both.
* The existing examples are `g.gui.iclass`, `g.gui.animation` and `g.gui.vdigit` which is closest to proposed `g.gui.nviz` because it is also integrated into wxGUI Map Display.
* The implementation should use/reuse/refactor the existing code and all current functionality should be preserved (comparisons with the original version should be done throughout the whole development period).
* The command line interface should be similar to `m.nviz.image` module but should also accept wxGUI workspace file.
* Some refactoring will be needed to uncouple GUI controls (now part of Layer Manager) and the rendering
* rule of thumb is that the new code should work even without GUI controls, e.g. as API, and the rendering should be possible not only in the wxPython window but also using `m.nviz.image` module
* usage in `g.gui.animation` could be considered too
* having a Python API might be quite advantageous for scripting (although `m.nviz.image` solves most of the problems)
* This would bring benefit to QGIS Processing which is using the standalone !Tcl/Tk NVIZ with GRASS GIS 6, so this project should be (co-)mentored by mentors from both GRASS GIS and QGIS projects.
* Language requirements: Python, wxPython, (C and OpenGL shouldn't be necessary)
* Other requirements: basic software design patterns and GUI programming experience
* Mentor: Anna Petrasova
* Co-mentor: Vaclav Petras
* Rating: medium
* Expected Outcomes: standalone GUI 3D viewer
* Test of skills: solving wXGUI-related [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&type=defect&version=svn-trunk&component=wxGUI bugs]
=== Integration of v.profile into GUI profiling tool ===
Current GUI profile tool supports creation of profiles of raster maps. It serves as a visualisation frontend to r.profile. Sometimes it is necessary to integrate into profile information on some objects (river, road, observation point etc.) that are provided as vector objects. Such functionality is provided by v.profile module, still any visualisation tool is lacking. Thus as a part of SOC existing profiling tool could be extended to include also vector profiling capabilities. This SOC requires basic knowledge of Python and will provide introduction into wxPython program development.
* Integration of v.profile should provide support of:
* displaying vector points as symbols by their Z coordinate / attribute value OR on a selected raster profile line
* displaying vector line crossing places as vertical lines
* displaying labels next to symbols or at X axis
* This can be extended by integrating also v.profile.points which is a different way of profiling vector maps.
* Requirements: Python, wxPython
* Mentor: ?
* Co-mentors: Māris Nartišs, Vaclav Petras (v.profile.points part)
* Rating: medium
* Expected Outcomes:
* Test of skills:
=== Add CMake build system for GRASS GIS ===
This idea will allow to have a cross-platform build of grass on all major platforms (GNU/Linux, *BSD, Windows and OSX)
students must have a advanced knowledge of writing cmake scripts and also should have access other oses: OSX, Linux and Windows (atleast a VM instance to do testing is required)
* Keep autoconf until cmake build becomes stable (atleast two releases ?)
* Requirements: CMake
* Mentor: Rashad Kanavath
* Co-mentors: ??
=== Add a cloud masking module for sentinel data in GRASS GIS ===
The idea is to implement a module for GRASS GIS to do the cloud masking using an automatic approach which do not use thermal bands and time series (Parmes et al. 2017). A number of test have been performed in the last month using the approach published in the cited paper and adding some additional consideration to better remove the shadow.
...
Students must have a advanced knowledge of writing python scripts in GRASS
* Requirements: Python / C / C++
* Mentor: Markus Neteler, Roberto Marzocchi
* Rating: medium
* Expected Outcomes: a new GRASS python script which perform the cloud masking
* Test of skills: good knowledge of Remote Sensing and in particular of Sentinel-2 data
* Accepted as wiki:GSoC/2018/CloudsAndShadowsDetection
=== Full support of Python 3 in GRASS GIS ===
The idea is to update core GRASS components for Python3. It consists of:
* finding best solution for dealing with unicode
* Python libraries (scripts, pygrass, temporal) - some of work already done but requires more work, testing and improvements
* Python modules (script) in SVN trunk
* wxGUI: update wxpython libraries and components to Python 3, wxGUI already mostly runs with wxPython Phoenix with Python 2, needs to be updated to Python 3
* Requirements: Python, wxPython
* Mentor: Martin Landa
* Co-mentors: Anna Petrasova, Vaclav Petras
* Rating: medium
* Expected Outcomes: GRASS ready for Python3 (GRASS 7.6)
* Test of skills: listing generally used solutions for migrating from Python 2 to 3 and listing possible solutions when dealing with unicode, tickets: #3510
* Accepted as wiki:GSoC/2018/FullSupportPython3
=== Improve GRASS integration in QGIS 3 ===
Currently GRASS integration in QGIS is hard to maintain. In QGIS Dev ML has been proposed to remove all external providers (namely OTB, GRASS, and SAGA) from Processing in QGIS2, see https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
The idea is to improve GRASS integration in QGIS 3 in order to be maintainable in the future. It consists several parts:
* Improve Processing integration
* Design automated system of managing GRASS modules UI in QGIS, see also https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI
* Consolidate GRASS modules handling both in Processing and GRASS plugin
* Improve GRASS plugin UI
* Improve GRASS data provider
* Requirements: C++, Qt, Python
* Mentor: Martin Landa
* Co-mentors: Rashad
* Rating: medium
* Expected Outcomes: Maintainable GRASS support in QGIS3
* Test of skills:
* Accepted as wiki:GSoC/2018/IntegrationInQGIS3
=== New easy-to-use CLI and API for GRASS GIS ===
* TL;DR: 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.
* GRASS GIS requires GRASS GIS Database, Location and Mapset to be set up to maintain data consistency, efficiency and security. Unfortunately, this is cumbersome when GRASS GIS is not the primary tool user is using.
* There are different ways for calling GRASS modules without starting iterative GRASS session:
* Modules executed with the `--exec` interface (see [https://grass.osgeo.org/grass74/manuals/grass7.html#batch-jobs-with-the-exec-interface the grass7 manual page] >=7.2)
* `GRASS_BATCH_JOB`: same as newer `--exec` but through environmental variable and more limited
* Use `grass.script.setup` package from GRASS GIS (requires boilerplate to add the packages on path first)
* Use the standalone `grass_session` package (new, see [https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#Python:_GRASS_GIS_7_with_an_external_library:_grass-session here])
* Set up environmental variables and "RC file" yourself (the classic method).
* None of these allows the user to skip the database setup phase. This leads to the need for constant reimplementing of setup, import and export steps in various software and environments including ''user scripts'' (in Bash, Python, R), QGIS Processing, gvSIG/SEXTANTE, uDig/JGrassTools, and all the web/server/cloud tools and applications which use GRASS GIS as a processing backend (e.g. PyWPS server).
* GRASS GIS itself can make it easier for the callers (at least in most cases) by implementing an interface which would allow to use GRASS GIS modules without explicit dealing with GRASS GIS database.
* The command line call using the proposed interface would look like these:
{{{
grass run r.lake elevation=some/file.tiff water_level=10 lake=some/new/file.tiff coordinates=100,520
grass run r.slope.aspect elevation=file://.../elevation.tiff aspect=file://...aspect.tiff
grass run r.slope.aspect elevation=https://.../elevation.tiff.zip aspect=file://...aspect.tiff
}}}
* Basic execution phases:
* The `grass` command would have to parse the command line, compare it with the module XML interface description, find the files which should be maps (either using `file://` and ideally anything else), potentially download and uncompress, and import (or link) them, and then call the actual command (GRASS module).
* The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import.
* Doing the work in GRASS rather than in the other software would allow GRASS to make the decision about the details, for example the data exchange (r.external vs r.import vs r.in.gdal - see [https://github.com/qgis/QGIS/pull/5426#issuecomment-345067457 comment from MarkusN for QGIS Processing issue] or [https://lists.osgeo.org/pipermail/grass-dev/2017-November/086598.html mailing list]).
* GRASS Database would be created with an appropriate Location (projection based on input files or additional CLI input).
* The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used).
* Computational region would be set based on input file(s) or additional CLI input.
* Module execution.
* The output maps could be be also linked (e.g. r.external.out) with projection same as input which is should be faster then export.
* Ideally export (as well as import) should work also with PostGIS and databases provided through GDAL/OGR.
* Proposal should discuss and address how advanced things such raster algebra, multi-map inputs and outputs, temporal framework, cartography and visualization tools will work (or what are the limits).
* Use should be able to always specify the details manually:
{{{
grass run --mapset=/some/directory/grassdata/ncspm/practice1 r.lake elevation=some/file.tiff ...
grass run --region="s=55600 n=60500..." --mask=some/mask.tiff r.lake elevation=some/file.tiff ...
grass run --crs=EPSG:3358 --mask=some/mask.tiff r.lake elevation=some/file.tiff ...
grass run --use=some/file_a.tiff --get=some/file_b.tiff r.slope.aspect elevation=file_a aspect=file_b
}}}
* The system behind the interface will be inherently fragile, so it is necessary to write large amount of tests which would check different combinations of data types and projections.
* All the underlying code is expected to be in Python, so the project should involve also creation of Python API on the way.
* Bonus tasks:
* Making this work for the GUI in the same way. It is expected that this would work for any `g.gui.*` modules too but implementing similar mechanism also for module dialogs is more work (but some basic implementation might be quite straightforward).
* Making this connected to the standalone `grass_session` package.
* Generalization of the API, so that it incorporates also the concept of remote sessions (see e.g. [https://github.com/wenzeslaus/g.remote g.remote on GitHub])
* Current GRASS code involved:
* source:grass/trunk/lib/python/script/setup.py (library function(s) for Location setup in Python)
* source:grass/trunk/lib/init/grass.py (full GRASS GIS standard startup "script")
* See also:
* Tickets:
* #2424 PyGRASS does not work when GRASS is invoked from outside because it is not possible to change path to dynamic libraries in running process
* #2511 Starting GRASS in mapset which is not owned by the user
* #2579 Specify command to be executed as parameter of grass command (patch) and other suggestion for CLI, especially see the comment:15:ticket:2579 which summarizes the remaining issues after closing the ticket
* #2639 grass command should read commands from stdin as an interpreter would do
* #2678 GRASS starts even when Mapset is locked
* #2679 Drop or fix setting of Location and Mapset using environmental variables
* #2681 Remove legacy meaning of LOCATION variable
* #2685 Add ignore lock flag to grass command
* #3537 Add functionalities `--tmp-location` and `--no-clean`
* Documentation:
* [https://grass.osgeo.org/grass74/manuals/grass_database.html GRASS GIS Database]
* [https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-script.setup grass.script.setup]
* Mailing list and wikis:
* [https://lists.osgeo.org/pipermail/grass-dev/2018-March/087764.html grass-dev New CLI GSoC Idea: Comments, Mentors, Students Needed] (whole thread)
* [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072979.html grass-dev QGIS Processing & GRASS (January 2015)]
* [http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly Working with GRASS without starting it explicitly]
* wiki:Grass7/VectorLib/OGRInterface
* wiki:Grass7/VectorLib/PostGISInterface
* Other projects (see also the ones linked in the text):
* [https://github.com/qgis/QGIS/blob/0a1382a0be36d408aebd227fb0066f68c513e41e/python/plugins/processing/algs/grass7/Grass7Algorithm.py QGIS Processing Grass7Algorithm.py] source code
* [https://github.com/moovida/jgrasstools/blob/530c87f26d220f3eeff9d2fb9d21abd8821c00c3/grass/src/main/java/org/jgrasstools/grass/utils/ModuleSupporter.java uDig's JGrasstools] source code
* [http://sextante.googlecode.com/svn/trunk/soft/sextante_lib/sextante_gui/src/es/unex/sextante/gui/grass/ SEXTANTE grass] source code (broken link)
* [https://github.com/geopython/PyWPS/blob/425f0eb160f60714a6705a24ba926e03690ab371/pywps/Grass.py PyWPS source code] and [http://pywps.wald.intevation.org/documentation/process.html PyWPS documentation] (broken link)
* [https://code.google.com/p/wps-grass-bridge/source/browse/trunk/?r=97 wps-grass-bridge] source code (broken link)
* Related discussions on mailing list:
* [http://lists.osgeo.org/pipermail/grass-dev/2015-February/073867.html On GSoC Proposal New easy-to-use...]
* [http://lists.osgeo.org/pipermail/grass-dev/2015-March/074433.html GSOC project proposal]
* Similar complex command line interfaces to learn from:
* Git (a classic example of subcommand interface)
* Docker (subcommand interface combined with running other commands inside a container)
* !GeoGig (needs to get geospatial data in and out)
* !ImageMagic
* radical changes in CLI interface between versions [https://legacy.imagemagick.org/script/index.php 6] and [https://www.imagemagick.org/script/command-line-tools.php 7]
* new CLI has a single `magick` command with many parameters
* GMT
* [http://gmt.soest.hawaii.edu/doc/5.3.2/GMT_Docs.html#new-features-in-gmt-5 radical changes in CLI interface between versions 4 and 5]
* new CLI has a single `gmt` command and subcommands
* Test and training tasks:
* Extend `--exec` functionality:
* Add `--tmp-location` which runs `--exec` in a database/location/mapset which are created at the beginning and deleted at the end. See #3537.
* Add `--clean` (current default) and `--no-clean` which say if `--exec` should clean the `.tmp` directory in the Mapset (for parallel execution). See #3537.
* Add `--lock` (current default) and `--no-lock` which say if `--exec` should lock the Mapset (for parallel execution). See also #2685.
* 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.in.gdal or r.import) a raster file (same for vector).
* Add `--link-raster=some/file.tiff` which links (r.external) a raster file (same for vector).
* Add `--export-raster=some/file.tiff` which exports (e.g. r.out.gdal) a raster file (same for vector).
* Add `--link-output-raster=some/file.tiff` which creates (r.external.out) a new (output) raster file (same for vector).
* Add features to `grass` executable interface:
* Make it possible to associate `*.gxw` files with `grass` executable (#1204) or at least add `--gui-workspace`
* Add `-c XY` and `-c LL` for simple unprojected and latitude-longitude Locations (compare options in the current CLI to wxGUI Location Wizard).
* Solve one of the tickets linked above.
* Proposal: Student needs to show understanding of the GRASS GIS Database structure and significantly extend on text above.
* Language requirements: Python
* Mentors: Vaclav Petras
* Co-mentors: Pietro Zambelli
== Tips for students ==
* If you have your own ideas we encourage you to propose them. Explain them on the [http://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list].
* If you like some idea here or from previous yeas, write about it on [http://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. Perhaps you can add some drawings or mock-ups. (here in a wiki page)
* 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 (trunk) from source and prepare environment for development:
* See links appropriate for you at [http://grass.osgeo.org/development/how-to-start/].
* If you get stuck with the setup, feel free to consult the [http://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 ([http://lists.osgeo.org/listinfo/grass-user grass-user], [http://lists.osgeo.org/listinfo/grass-dev grass-dev]), fix some [http://trac.osgeo.org/grass/report 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. You should start even before 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 [http://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_2017 OSGeo GSoc Ideas page].
@
@
