}}}
= GRASS Google Summer of Code 2017 =
[[TOC]]
== About ==
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2017 The OSGeo GSoC 2017 main page]
* [https://summerofcode.withgoogle.com/ Official GSoC 2017 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]) 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`).''
=== Enhance 3D rendering capabilities ===
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
=== 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
* Potential co-mentors: Massimo Di Stefano, Pietro Zambelli
=== 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)
=== 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
=== 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
=== v.in.osm enhancement ===
!OpenStreetMap is a powerfull dataset. A module to import these data is needed. Until now a script, called [https://grass.osgeo.org/grass70/manuals/addons/v.in.osm.html v.in.osm], exists, but it is able to import data only from a PostgreSQL database after using [http://wiki.openstreetmap.org/wiki/Osm2pgsql osm2pgsql] to convert OSM format to PostgreSQL/PostGIS. This project has to implement the capabilities to import directly the .osm or .pbf format. It should use different backend to import the data, the different options could be:
* [http://wiki.openstreetmap.org/wiki/Osm2pgsql osm2pgsql] using PostgreSQL/PostGIS
* ogr library through [http://www.gdal.org/drv_osm.html OSM format]
* [http://imposm.org/ impoosm] version 2 is written in Python, version 3 is written in [https://golang.org/ go language]
* could be possible to develop a C library to convert OSM data directly inside GRASS
* Language requirements: Python, C
* Co-mentors: Luca Delucchi, Pietro Zambelli
=== 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: ?
* Co-mentor: Vaclav Petras (coding part)
* With support from: Moritz Lennert (with limited time available, though)
=== SOS tools ===
Sensor Observation Service is a OGC standard increasing its diffusion worldwide, the idea is to create a series of modules to get data from SOS server. The modules should use OWSLib to get in touch with the server and parse the responses, probably also some improvements should be done in this library to work correctly with all the servers. All the modules should give to the user the capabilities to get info about the sensors and filter the results for: sensors, range of dates and observedProperty
The modules to develop are:
- v.in.sos: able to create a GRASS GIS vector with or without the observations values.
- r.in.sos: able to create a GRASS GIS raster for each queried day
- t.vect.in.sos: able to create a space time vector dataset
- t.rast.in.sos: able to create a space time raster dataset, probably for this could be used t.vect.in.sos and later use a new module (to be developed in this project) t.vect.to.rast to convert space time vector dataset into space time raster dataset or the r.in.sos module
* Language requirements: Python
* Mentor: Luca Delucchi
=== 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.
=== Higher level API for C and C++ ===
* There is a lot of code which many modules replicate over and over. A most prominent example is perhaps random access to raster values.
* The goal of the project is to make writing of modules in C and in C++ much easier and reduce duplication of code among the modules.
* Proposal must identify potential areas which need a higher level API and what features would the API provide in comparison to the current API (and when it would be just enough to extent the current API).
* Possible improvements include:
* Random access to raster values which supports all-in-memory approach and hides implementation details such as row-based storage and separate segmentation (C version implemented in r70478).
* Unified access to a series of maps (list, group, spatio-temproal dataset) which hides potential improvements towards direct support of NetCDF series or Rasdaman.
* C++ interface leveraging C++ features such as operator overloading or support of STL algorithms.
* Bridging of C++ RAII and try-catch with GRASS GIS C API exit and optional memory cleaning must be addressed.
* Language requirements: C and C++
* Mentor: Vaclav Petras
* Potential co-mentor: Soeren Gebbert
* This idea needs extending and evaluating. A possible alternative is RCP interface in Python which also solves issues related to building persistent applications (e.g. GUIs) based on GRASS GIS libraries.
=== 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
=== 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
=== 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.
=== 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
=== GRASS GIS Locations created from public data ===
The organisation of data in Location and Mapsets in the GRASS GIS database is often one of the biggest problems for GRASS novices (see also discussion here: http://lists.osgeo.org/pipermail/grass-dev/2015-January/073268.html). The reasons can be that GIS novices and users of some other GIS software (which often tries to hide projection complexity), are not used to solving projection issues, or are not used to centralized organization of their data. However it is also one of the big strength of GRASS GIS esp. in a multi-user environment. This project aims at automatized organization of open, real world data in a GRASS GIS database which can be provided for download. This database will serve as an example for clever organization of spatial data in GRASS GIS and therewith illustrate this feature to new users and help understanding it`s concept. At the same time it provides ready to use real world data (which sometimes comes formats targeted at proprietary software) so that starting working with GRASS becomes more efficient.
* There are some datasets freely available such as OSM, US government data or some INSPIRE (see also: http://grasswiki.osgeo.org/wiki/Global_datasets).
* The task of the student would be to write scripts which can run on a server and create GRASS Locations which will be made available for download.
* Additional metadata must be generated too such as web pages and XMLs with links to provide access to these datasets.
* This project should also prepare an infrastructure, so that in the future users can contribute their country-specific scripts.
* Finally, the project would involve writing of a GUI interface integrated into wxGUI start/welcome screen which would offer download of the location.
* This can be also combined with the standardized [wiki:SampleDataset GRASS GIS Sample Dataset]. Maps would get standardized names and one would for example select different area to focus on, e.g. script would be able to download data for the whole USA with focus on North Carolina (creating maps according to the standardized sample dataset) but user can change it to focus on California (semantics and extent of maps would be the same).
* Scripts should be usable as standalone scripts when downloaded separately (so user can download some fresh data or can import into an existing GRASS Location or create a new Mapset). Compatibility with the [http://live.osgeo.org OSGeo Live] sampler DVD would be a major bonus.
* Original metadata should be preserved, distributed with the data and used to create a description in the download side and in the GUI.
* Requirements on student:
* Basic knowledge of GRASS scripting, wxPython, HTML/XML, and UNIX is needed. Some (again basic) understanding of downloading and online protocols will be necessary for data acquisition.
* Deep knowledge of GRASS GIS is not necessary.
* The student must be prepared to work with many different data sources and perhaps contact people from community to get suggestion where and how to get the data.
* Language requirements: Python (Python would the the primary tool used), Bash, wxPython (basics)
* Mentor: ?
* Co-mentor: Vaclav Petras (coding and GUI integration part)
=== 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 add-on (planned to be moved from add-ons to main modules), 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 (addon module) 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)
=== Implement cutline generation ===
Finding 'meaningful' cutline in an scene could be very interesting for tiling images and process segmentation in parallel. Instead of using arbitrary linear tiling, the segmented tiles could then be merged without post-processing of segments touching the tile's border. The proposition is to implement a method described in [1] for cutline generation (see [2] for more references).
The procedure is composed of the following main steps:
1) Apply a High-pass filter - the "Prewitt South" filter (https://en.wikipedia.org/wiki/Prewitt_operator) to produce an edge image;
2) Apply a low-pass filter (mean for example) on the previous result;
3) Find the starting and finishing points (just based on pixel values in the first/last column/row);
4) Create an adjacency matrix on the result of 2) and use weights to give higher costs for specific directions (and force the cutline in to be quite linear between starting and finishing points);
5) Use the Dijkstra's algorithm (https://en.wikipedia.org/wiki/Dijkstra's_algorithm) to find the optimal cutline with a lowest cost between the starting and finishing point
If this algorithm would be implemented during the GSoC, it could be further adapted for huge enhancement of i.image.mosaic to enable mosaicking of adjacent scenes using cutline and become a real alternative to proprietary software (http://gis.stackexchange.com/questions/127310/how-to-create-a-mosaic-in-qgis-with-cutline-and-feathering-for-landsat-8-imagery). As the proposed solution for cutline is working on a single image, It should be adapted to take into account the pixels values of two images so.
[1] Soares, Anderson Reis, Thales Sehn Körting, et Leila Maria Garcia Fonseca. 2016. « Improvements of the divide and segment method for parallel image segmentation ». Brazilian Journal of Cartography 68 (6). https://www.researchgate.net/publication/286929006_Improvements_of_the_divide_and_segment_method_for_parallel_image_segmentation
[2] Körting, Thales Sehn, Emiliano Ferreira Castejon, et Leila Maria Garcia Fonseca. 2013. « The Divide and Segment Method for Parallel Image Segmentation ». In Advanced Concepts for Intelligent Vision Systems, 504 15. Springer, Cham. doi:10.1007/978-3-319-02895-8_45. https://www.researchgate.net/publication/265794792_The_Divide_and_Segment_Method_for_Parallel_Image_Segmentation
* Language requirements: C/C++ ?
* Technical mentor: ??
* Thematic mentor: Anderson Soares
* With support from: Taïs Grippa
== 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.
* GRASS GIS hopes to participate 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 [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016_Ideas OSGeo GSoc Ideas page].
@
@
