@ @

GRASS Google Summer of Code 2014

About

• ​The OSGeo GSoC 2014 main page
• ​Official GSoC 2014 page at Google

Ideas

Post your ideas here or to the ​grass-dev mailing list if you want to discuss them more. To edit this wiki, you need to ​login with an ​OSGeo Userid; read also some help for using trac.

You are invited as well to have a close look at (and re-suggest!) ideas from previous years (​2007, ​2008, ​2009, ​2010, ​2011, ​2012, ​2013) which have not yet been implemented. You can also look at accepted GRASS GSoC projects from previous years for an idea of scope.

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 supbages 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/2014/WebGRASSIdea) from the possible student project page (e.g. GSoC/2014/WebGRASS).

Metadata for GRASS GIS maps and datasets

• GRASS supports basic metadata or descriptions but not the advanced large metadata as defined, e.g. by ISO.
• Current metadata standards should be supported/fulfilled, and multiple schemas/definitions should be possible, special interest is in the explicit support of INSPIRE.
• This project has two parts:
  • The implementation of backend (library), storage format and modules to manipulate metadata.
  • The GUI frontend to edit, import and export metadata.
• All GRASS datatypes should be supported: rasters, 3D rasters, vectors and temporal datasets.
• Relation to existing tools should be considered (G7:r.info, G7:v.info, G7:r.support, G7:r.timestamp, t.* modules).
• Compatibility with other GIS systems should be considered, especially QGIS, gvSIG and GDAL/OGR.
• Possible implementation is a separate file in arbitrary XML format and its definition and transformation to other formats (this would be independent on other tools).
• Prepare a sample dataset for North Carolina (we'll help source the data)
• Requirements on student:
  • Familiarity with XML and UML
  • This project does not require deep knowledge of GRASS since metadata are (or can be) mostly independent on rest of the things.
  • Student must be proactive and consult the project with GRASS users from different countries (continents).
• Discussion: ​Proposal for GSoC idea on INSPIRE (​nabble, ​gname)
  • OWSLib is written in Python, in the OSGeo family pycsw is already using it (see ​http://geopython.github.io/pycsw-workshop/docs/advanced/advanced-exercises.html)
• Student: Matej Krejci
• Mentor: Margherita Di Leo (dileomargherita AT gmail DOT com)
• Co-mentor: Martin Landa (landa.martin AT gmail DOT com)

Compiling GRASS GIS on Android

• The C part, with libraries and modules (already partly done, but not on trunk and not with updated dependencies).
• The GUI, is there any path through Vaclav's ​remark in FEM code sprint last year about wxWidgets (not yet ​wxPython, ​Phonenix version maybe) application rendered as HTML5 using ​GTK+ Broadway (which is probably more suitable for server-client application), or any other possibility?
• Output expected 1) a SVN trunk directory with sufficient material for setting up your own Android compilation.
• Output expected 2) a Android nightly binary for Android 4.x for the GRASS GIS text version
• Output expected 3) a route to explore the GUI options, or a proof of concept (display maps, or display modules GUI independently)
• Discussions: ​Android Compilation, ​GSoc Compiling GRASS GIS on Android
• See also the GRASS on Android ​wiki page
• Student: Barun Paudel (paudel.barun4 AT gmail DOT com)
• Mentor: Yann Chemin (ychemin AT gmail DOT com)
• Co-mentor: Nimalika Fernando (nimalikaf AT gmail DOT com)
• Co-mentor: Maybe somebody with wxPython experience (in case that it is possible to run wxPython on Android)

Web-based GUI for GRASS GIS

This idea will consist in building a web application "WebGRASS" which allows to run GRASS modules on modern browsers.
The user interface for WebGRASS will be built using ​Wt , Web Toolkit .
WT provides C++ API and python bindings (available on ​github) for developing web widgets.
Each grass module is described by an XML file generated the module's --interface-description parameter, the xml file is then parsed to generate the Module Form interface.
Parsing of the xml file and generating tokens is already available in GRASS GIS.

The main User Interface will be composed by :

• Auth-module (user log-in)
• mapset-location wizard
• map canvas (based on openlayers)
• menu bar with same layout of grass desktop
• toolbar with:
  • pan
  • query
  • zoom in - out - to bbox - to layer - to region
  • save to img mapcanvas
  • save display extent to region

• Command line prompt (a GRASS shell based on IPython Notebook)

Security concerns

By default Web-GRASS is designed to allow access to trusted users.
Each user will be an UNIX user on the server with his own home.
The web-grass UI interface will be accessible through an opportune registration/auth/login framework.
The communication over the network will be encrypted using HTTPS.
The imput parameters will be parsed and sanitized, this will be part of the UI itself, based on the ​GRASS command-line parsing
Will be choice of deployment team to decide to adopt any 'Extra security layer'. This can be achieved using tools like :

• ​docker
• ​lxc
• ​supervisors
• ​ulimit

Discussion on the grass-dev mailing-list ​GRASS GIS Web UI

• Language requirements: C++, Python
• Mentor: Mohammed Rashad
• Co-Mentor: KS Rajan
• Student: ​Massimo Di Stefano

Testing framework for GRASS GIS

• GRASS GIS needs automated testing mechanism which should:
  • be part of the main source code to be actually used
  • be at least somehow easy to use, so that everybody can write tests
  • be cross-platform, so that it runs even on MS Windows where tests are desperately needed
• The purpose of this project is to develop a general mechanism which would be applicable for testing GRASS modules, libraries or workflows with different data sets.
• Several sample tests for different parts of code, especially modules, will be written to test the testing framework.
• The testing framework will permit usage of different testing methods such as doctests, Python scripts, Shell scripts or even compiled C programs, although they might not be applicable for all platforms. This will enable the possibility to use existing tests in GRASS source code and also user scripts as test cases in the proposed testing framework.
• The testing framework will enable the use of different testing data sets because different test cases might need special data.
• The testing of GUI in terms of the graphical user interface itself will not be covered by this project. However, the developed testing method should be applicable to testing of GUI internal functionality.
• The test suite would be implemented in Python and based on testing tools included in standard Python distribution (​unittest and ​doctest). The goal is not to write from scratch but also not to bring a new dependency.
• The usage of Makefile system will be limited to triggering the test or tests with the right parameters for particular location in the source tree.
• Previous work:
  • Missing guidelines for testing ticket (#2105)
  • ​Test Suite proposed at ​Prague 2011
  • Older test suite from Soeren Gebbert
  • ​GRASS GIS Quality Assessment and monitoring list
• Discussion: ​GSoC idea: Testing framework (​nabble, ​gmane)
• Student: Currently in discussion
• Mentor: Soeren Gebbert
• Co-mentor: Helena Mitasova

Vector legend for GRASS GIS

• There is currently a G7:d.legend module which creates legend for raster maps; implementation for vector maps is missing so we need a new module: d.vect.legend.
• Vector legends should integrate with G7:d.vect, G7:v.colors, 3D (G7:wxGUI.Nviz), G7:ps.map, and probably attribute (database) tables in general.
• The usage of the vector legend in the wxGUI should be part of this project.
• The thematic mapping should be considered or even part of this project.
• If there is time, feature requests for G7:d.legend (i.e. d.rast.legend) should be considered too:
  • #89 Option to read data range from stdin instead of raster
  • #1049 Optional histogram sidebar for floating-point raster legends
  • #2083 Add 3D raster (volume) support to d.legend
• Language requirements: C, Python, wxPython
• Co-mentor: Martin Landa (landa.martin AT gmail DOT com)
• Co-mentor: Hamish Bowman (hamish_b AT yahoo DOT com)

Extracting the medial axis of polygons

The medial axis, sometimes also called topological skeleton, is a line version of a polygon where all points on the lines are equidistant to the polygon's boundaries. The medial axis can be used to extract the center line of a polygon, useful e.g. to convert a river represented as a polygon to a line, but also for characterising a polygon's shape, e.g. for object-based classification of images. While the theory for extracting a medial axis is well known, actual implementations often use an approximation instead of the exact medial axis. Extracting the exact medial axis poses problems with regard to floating point accuracy around concave vertices where the medial axis has the form of a parabola. A collection of algorithms exist to define parabola equations around concave vertices, intersect parabolas, and approximate parabolas with straight line segments. A working implementation is not yet available for GRASS.

• Language requirements: C
• Mentor: Markus Metz

Visualization of large point clouds in 3D in GRASS GIS wxGUI

• Optimize NVIZ (OGSF, wxNVIZ) in order to display large 3D point clouds.
• It would be nice if also 2D display would be optimized or at least considered in this project.
• Speed wish from 2011: wxNVIZ should be able to rotate point cloud (i.e. LiDAR dataset) with 4 millions of points on medium hardware (i.e. 2GHz CPU with 2Gb RAM and GPU with hardware transform and lighting support and dedicated video RAM) with response time not greater than 1.0 second.
• If a special GUI addition to existing wxNVIZ would be required, it should be implemented in this project.
• Language requirements: C, Python, wxPython, OpenGL

Color table management GRASS GIS wxGUI

• Color tables/rules can be easily set from command line or GUI using rules input. However, to edit current color table, you must run another modules and then copy and paste the existing rules. Moreover, for today's GUI users, the text only way is not as smooth as point-and-click. Even advanced users could benefit from the fact that they see the colors which they editing and perhaps a preview of the legend which would be generated for the map.
• The task: Create a color and interval editor tool which should be able to create text files that are compatible with G7:r.reclass, G7:r.colors, G7:v.colors and friends.
• The existing GUI tools (Raster -> Manage colors -> Manage color rules interactively and its friends for vector and in 3D) are arguably cumbersome, not stable, ..., and should be improved.
• Easy to use GMT color table format (CPT) importer would be a big advantage. There is already a r.cpt2grass converter for them available as an addon module, for example color tables from the ​cpt-city repository. (see also QGIS's mirror of cpt-city; licenses would need to be vetted)
• Integrate categorical and interval colors from ColorBrewer.
• In the wxGUI: Instead of having the color rules stored in the file passed to G7:r.colors rules option, there could be a button from the color management menu which would bring user to the manager/editor, allowing true interactivity, color etc. then automatically launching G7:r.colors with the given rules.
• It might also be advantageous to save the name of the color table after G7:r.colors somewhere in files for map, so that it can be reused/displayed later. (probably easiest to allow the colr/ files reading code to ignore #commented lines and put the name at the top of the colr/ file)
• Language requirements: Python, wxPython
• Co-mentor for C and API parts: Hamish Bowman
• Co-mentor for design and testing: Helena Mitasova

Path sampling library for GRASS

• GRASS currently has two modules which use path sampling method for overland flow simulation and sediment transport modeling. An additional GRASS python module uses the method to simulate aeolian sand transport.
• The code in the modules is not well designed for further extensions so it will be useful to write a path sampling method library which would enable rapid and efficient development of modules for modeling surface and subsurface water and pollutant flow, water and aeolian sediment transport, fire spread and many other types of fluxes (including movement of people) in complex, spatially diverse environments.
• The library should support stationary and time dependent processes and provide a foundation for development of steered simulations.
• The output expected:
  • library which offers the functionality for path sampling based modeling
  • at least one module built with this library - for example a new, cleaner version of G7:r.sim.water can be used as a test case.
• Language requirements: C
• Mentor: Helena Mitasova

GRASS GIS locations created from public data

• Creating a location is often one of the biggest problems for GRASS novices, for various reasons. 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 they don't know where to find geo-data.
• This should not provide sample data for tutorials and manual but real data for the real work.
• There are some datasets freely available such as OSM, US government data or some INSPIRE.
• 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.
• Scripts should be usable as standalone scripts when downloaded separately (so user can download some fresh data or can import into an existing location). Compatibility with the ​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 understanding of downloading and online protocols will be necessary for data acquisition.
  • Deep knowledge of GRASS 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: Bourne shell scripting, Python

GRASS GIS raster attribute tables

• Implement the raster attribute tables for 2D and for 3D rasters which would work similarly to attribute tables for vectors.
• Attribute table can be filled with statistical data associated with one category, label (defined using G7:r.category), color (defined using G7:r.color) or generally it can contain any attributes as in case of vector attribute table.
• See also G7:r.out.gdal -t flag (r58890) and G7:r.in.gdal (r54284) for reading and writing a GDAL raster attribute table (mainly related to colors).
• A solid working knowledge of GRASS raster maps would be helpful.
• Language requirements: C, SQL

GRASS GIS Map display decorations enhancements

• There are currently various map decorations/elements available: raster legends (using G7:d.legend), barscale (using G7:d.barscale), north arrow (using G7:d.northarrow) and text (using wxPython).
• This project would add the possibility to add shapes such rectangle or circles into the main map display by enhancing and creating a wxGUI front-end to the G7:d.graph module. Thanks to this, it would be possible to annotate the map in a simplified way (comparable to displaying a vector point).
• Moreover, the project would implement the possibility to add any d.* command or their combinations (using SimpleLayerManager) to the map display as a smaller image. This would enable to create wxGUI displays with more than one raster legend and also displayed views with smaller area overview, or area detail in one of the corners (already possible, without GUI support, in G7:ps.map as a two step process involving the eps instruction).
• The possibility to add external images would also significantly improve the possibilities and would enable things such as adding logos to maps. For this a SVG import tool or converter would be added to the G7:d.graph module.
• Different decoration proposed here and even those already present would benefit from a map decorations/elements manager (similar manager is present in G7:g.gui.animation).
• It should be possible to control at least the simple decorations from GUI Command console (or system command line in case of G7:d.mon wx*). This also relates to the fact that existing modules in GRASS 7 and GRASS 6 should be considered such as those used to add text and points (markers).
• As many decorations as possible should be implemented also for 3D visualization mode (wxNVIZ) which may or may not interfere with requirements from the previous point.
• All decorations should be supported by the export (save display to file) function because image outputs are the primary motivation of this project.
• Language requirements: Python, wxWidgets, perhaps some C
• Co-mentor for design and testing: Helena Mitasova

Porting of g.infer to GRASS GIS 7 for rule-based analysis and workflow control

• The add-on module ​g.infer for GRASS 6.4 provides a full rule-based inference engine for the use within GRASS.
• Rule-based inference can be used both to analyse existing data layers (raster, 3D rasters, vectors points) but also to dynamically control GRASS-based workflows, including simulation models, agent-based simulation, and active retrieval of external input data.
• g.infer is based on the ​CLIPS expert system shell using the Python module ​PyClips.
• Porting the module to GRASS 7 (trunk) requires an object-oriented redesign of the g.infer architecture (currently, functional programming is used)
• A deep integration based on the GRASS 7 Python API is desirable.
• Language requirements: Python
• Mentor: Peter Loewe

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. 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 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 ​grass-user mailing list.
  • Familiarize yourself with the various SUBMITTING files in the top level of the source code.
• Prove your worth by being active on the GRASS mailing lists (​grass-user, ​grass-dev), 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.

• GRASS GIS hopes to participate 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 GSoc Ideas page.

Accepted proposals

The template for this part is ​here.

The student page with the tracking of the project should be child of this page, e.g. GSoC/2014/TemporalGISAlgebra. Additionally, the project itself may have also its own page if it seems to be larger than the GSoC project, e.g. Grass7/TemporalGISAlgebra (the name does not have to be the same and it does not have to be subpage of any page).

Note that Google material for the application does not have to be accessible, so it is better to include important information (such as idea description) to the student page.