[[TOC]]
{{{
#!html
@
@
}}}
= GRASS Google Summer of Code 2015 =
== About ==
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2015 The OSGeo GSoC 2015 main page]
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Official GSoC 2015 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]) 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/2015/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2015/CoolGRASSProject`).''
=== 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
=== New easy-to-use command line interface for GRASS GIS ===
* 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 tools one is using. There are different workarounds for calling GRASS modules without starting GRASS explicitly, or running GRASS in a batch mode. However, none of these allows one to skip the database setup phase. This leads to the need for constant reimplementing of setup, import and export steps in various environments including user scripts (Bash, Python, R), QGIS Processing, gvSIG/SEXTANTE, uDig/JGrassTools and all the web/server/cloud tools which use GRASS GIS as a processing backend.
* 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 this:
{{{
grass run r.slope.aspect elevation=file://.../elevation.tiff aspect=file://...aspect.tiff
grass run r.lake elevation=some/file.tiff water_level=10 lake=some/new/file.tiff coordinates=100,520
}}}
* The `grass` command would have to parse the command line, find the files which should be maps (either using `file://` or perhaps anything would work) and import/export/link them, and then call the actual command.
* The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import.
* The output maps could be be also linked (external) with projection same as input which is should be faster then export.
* Ideally this should work also with PostGIS and databases provided through GDAL/OGR.
* The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used).
* This project should also contain a [https://github.com/qgis/QGIS QGIS] Processing part.
* Since QGIS Processing is one of the reasons for this interface, implementing is a crucial use case which should be tested from the very beginning a with QGIS Processing implementation, the interface would be used right away.
* Alternatively, another project or more than one project can be in this part.
* Title should change according to decisions made about this part.
* Proposal should discuss how advanced things such raster algebra, multi-map inputs and outputs, temporal framework, cartography and visualization tools will work.
* 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.
* Bonus task would be to find/implement a way to run Python code easily in case `grass` is called from Python (`grass python -c "print('...')"` is a good start).
* It is expected that this would work for any `g.gui.*` modules too but implementing similar mechanism also for module dialogs is out of scope of this project (although some basic implementation might be quite straightforward).
* Language requirements: Python (both GRASS GIS startup scripts and QGIS Processing are in Python)
* See also:
* #2579 Specify command to be executed as parameter of grass command (patch) and other suggestion for CLI
* [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072979.html grass-dev QGIS Processing & GRASS (January 2015)]
* #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
* [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
* [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
* [https://github.com/geopython/PyWPS/blob/425f0eb160f60714a6705a24ba926e03690ab371/pywps/Grass.py PyWPS source code] and [http://pywps.wald.intevation.org/documentation/process.html PyWPS documentation]
* [https://code.google.com/p/wps-grass-bridge/source/browse/trunk/?r=97 wps-grass-bridge] source code
* Mentor for the GRASS GIS part: Vaclav Petras
* Mentor for the QGIS part: ?
* Mentor for the part: ?
* Co-mentors (e.g. PostGIS connection part): ?
=== Complete basic cartography suite in GRASS GIS wxGUI Map Display ===
* With few additions the wxGUI Map Display could cover large number of cartography needs so that users wouldn't be forced to switch to [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer] or different software (Inkscape, QGIS) to create fully-featured map usable, e.g. for scientific publications. The development can happen in phases so that the easy-to-implement things, which gives greatest gain, are done first.
* first phase:
* store legend, scale bar, north arrow and text (and others if added) in workspace (#2369)
* add units to legend (optionally also title) as parameter
* possibility to add any image (as in animation tool), use cases: logo/watermark, workaround for overview maps
* disable rendering when loading workspace
* determine map window size without the need to change map display size manually
* second phase:
* support map units in scale bar, not only meters
* allow user to set the length of scale bar (in map units)
* manual breaks for legend
* legend background
* general shapes
* can be implemented using `d.*` commands (e.g. `d.graph`) or wxPython or both (wxPython might be easier for interactivity, `d.*` commands for scripting)
* use cases: workaround missing backgroud of legend or text, manual marking special points
* include map-display-like object
* would be represented as image but the image would be dynamically generated
* useful for overview maps (insets) or histograms
* might be implemented as a standard Map Display whose saved image would be inserted as an image, perhaps image from other Map Display can be used
* the important feature is the user does not have to create an intermediate file
* third phase:
* implement vector legend:
* Perhaps we can find some workaround (i.e. some easy implementation) and wrap it into a module, e.g. vector legend drawn as vector with attribute table (enables even line with border thanks to different vector layers).
* May get complicated with (enhancements of) vector thematic mapping
* enhance `d.vect.thematic`
* make `d.text`, `d.graph`, `d.erase` and perhaps other existing `d.*` modules accessible from wxGUI
* implement module which can parametrize workspace (similarly as `g.gui.animation` is doing for 3D View) and render it with different maps
* if the implementation would be wxPython free (ideal option) then it would have to translate some wxPython/wxGUI specific things to plain `d.*` commands
* this can be also implemented as a script generator (rather than workspace renderer)
* it should work as a simple automatic map ("atlas") generator and should accept also time series as the input
* It would be great to make as much things as possible to work also in 3D Views (wxNVIZ).
* Thorough (manual) testing on different platforms is needed (by student or mentors).
* See also:
* [wiki:GSoC/2014#GRASSGISMapdisplaydecorationsenhancements map decorations idea from last year]
* [wiki:GSoC/2014#VectorlegendforGRASSGIS vector legend idea from last year]
* #2582 (implement `d.vect.thematic2` addon module features in `d.vect.thematic` core module)
* [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072918.html grass-dev future of thematic mapping in GRASS]
* [http://lists.osgeo.org/pipermail/grass-dev/2010-March/049414.html grass-dev future thematic cartography in GRASS]
* [wiki:GSoC/2014#ColortablemanagementGRASSGISwxGUI slightly related color tables idea from last year]
* #2080 (changing properties of barscale or legend)
* Language requirements: Python, wxPython, (perhaps a little bit of C and OpenGL)
* Co-mentors: Anna Petrasova, Helena Mitasova, Martin Landa
=== 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
=== 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 [http://www.webtoolkit.eu/wt Wt], Web Toolkit.
* WT provides C++ API and python bindings (available on [https://github.com/wdu/pywt 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 input parameters will be parsed and sanitized, this will be part of the UI itself, based on the [http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html 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:
* [https://www.docker.io/ docker]
* [https://linuxcontainers.org/ lxc]
* [http://supervisord.org/ supervisors]
* [http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds5/ulimit.htm ulimit]
* Discussion on the grass-dev mailing-list [http://lists.osgeo.org/pipermail/grass-dev/2014-March/067665.html GRASS GIS Web UI]
* Detailed [http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/massimo_di_stefano/5685265389584384 Idea description]
* [wiki:GSoC/2014/WebGRASS page for more broad idea description including alternatives] (unfinished)
* Language requirements: C++, Python
* Mentor: ?
* Co-Mentor: ?
* Sample !PyWt implementation to call GRASS commands from a !PyWt web UI by [http://wiki.osgeo.org/wiki/User:Epifanio Massimo Di Stefano]
* [https://github.com/epifanio/wgrass source code]
=== Improved Metadata for GRASS GIS ===
* During last years Google Summer of Code Matej Krejci developed ISO-based Metadata support for GRASS 7.1 [http://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS]
* This project aims at continuing this work by:
* Adding CSW-T support for saving and updating metadata in metadata catalogs (e.g. [http://geonetwork-opensource.org/ GeoNetwork] or [http://geonode.org/ GeoNode]).
* Adding an option for fetching predefined metadata values from metadata catalog databases e.g.: keyword lists, points of contacts, ... or alternatively (for those who do not use Metadata catalogues) store such values in a DB (the backend used in GRASS GIS)
* Adding support for temporal datasets (TGIS)
* Adding functions for metadata export to other formats (e.g. PDF)
* Fixing minor enhancements and bugs listed on http://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS
* Compatibility and synergies with other GIS systems should be considered, especially QGIS, gvSIG and GDAL/OGR.
* 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).
* 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)
* Mentor: ?
* Co-mentor: ?
=== 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: 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.
* 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 [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 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
* Mentor: ?
* Co-mentor: ?
=== GUI plugin system for GRASS GIS ===
GRASS GIS allows to install addons/extensions from GRASS Addons using `g.extension`. This works well for GRASS modules but it is not sufficient when things needs to be integral part of wxGUI.
* The main tasks are to write
* a GUI which would manage and install the plugins,
* mechanism which would load the installed and activated plugins and
* an interface which plugins would use to communicate with GIS and integrate themselves into GUI.
* GUI plugins should use the `g.extension` system in the background. The difference is that you may want to have more plugins installed but just a subset would be activated. Perhaps, GUI plugin manager can just take care of turning plugins off and on and setting for individual plugins while `g.extension` and wxGUI `g.extension` will take care of installation and related things (which should be possible in any case).
* Some extensions may provide both GUI plugin and a standalone `g.gui.*` module (this is actually an ideal case).
* Some GUI plugins may depend on a particular extension or even a Python package the extension installs.
* Some GUI plugins may include or depend on some particular addons (group of extensions to install) or GUI toolbox (a file used to construct a menu).
* Some plugins may include general files such as default configurations or images.
* There is already an interface to communicate with GUI but it needs to be extended and improved. Also there should be a defined interface which plugin itself should provide (name, description, ...).
* GUI plugin system should work the same for GUI plugins installed manually and installed using `g.extension`.
* Several use cases should be explored and used as examples.
* It would be good to consider (at least for the sake of real use case) turning some existing parts or wxGUI into plugins, e.g. vdigit, rdigit, iclass or various plots.
* Bonus task is to extend `g.extension` in the way that it supports local source code (#1652) and individual extensions as source code in GitHub (might be almost possible now using Subversion).
* Language requirements: Python, wxPython
* Mentor: ?
* Co-mentors: Vaclav Petras, Anna Petrasova
== 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.
* 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_2015_Ideas OSGeo GSoc Ideas page].