[[TOC]]
{{{
#!html
@
@
}}}
= GRASS Google Summer of Code 2014 =
== About ==
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2014 The OSGeo GSoC 2014 main page]
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Official GSoC 2014 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.
''Some bigger ideas may have their own pages, so you can link them here. You can also have a 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]) and [wiki:GSoC projects from previous years].''
=== 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).
* Requirements on student:
* 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: [http://lists.osgeo.org/pipermail/grass-dev/2014-January/067052.html Proposal for GSoC idea on INSPIRE] ([http://osgeo-org.1560.x6.nabble.com/Proposal-for-GSoC-idea-on-INSPIRE-td5100471.html nabble], [http://comments.gmane.org/gmane.comp.gis.grass.devel/56366 gname])
=== 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 [http://geo.fsv.cvut.cz/data/osgeorel/2013-04-fem-gis/petrasova-petras-fem-gis-2013-04.pdf remark] in FEM code sprint last year about wxWidgets (not yet [http://trac.wxwidgets.org/ticket/14469 wxPython], [http://trac.wxwidgets.org/ticket/15291 Phonenix version] maybe) application rendered as HTML5 using [https://developer.gnome.org/gtk3/stable/gtk-broadway.html 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)
=== 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 ([http://docs.python.org/2/library/unittest.html unittest] and [http://docs.python.org/2/library/doctest.html 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)
* [http://grasswiki.osgeo.org/wiki/Test_Suite Test Suite] proposed at [http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Prague_2011#Testing_and_benchmarking Prague 2011]
* Older test suite from Soeren Gebbert
* [http://lists.osgeo.org/listinfo/grass-qa GRASS GIS Quality Assessment and monitoring list]
* Student: Vaclav Petras
* Mentor: Soeren Gebbert
=== Vector legend for GRASS GIS ===
* There is currently a G7:d.legend which creates legend for raster maps; implementation for vectors is missing.
* Vector legend should work with G7:d.vect, G7:v.colors, 3D (G7:wxGUI.Nviz) and probably attribute table in general.
* The usage of the vector legend in the wxGUI should be part of this project.
* There should be a possibility to combine raster, 3D raster and vector legend together.
* The thematic mapping should be considered or even part of this project.
* The feature request for G7:d.legend should be considered too:
* #89 Option to get info from stdin instead of raster
* #2143 Add option to output legend definition as text
* #1049 Optional histogram sidebar for legends
* #2083 Add 3D raster (volume) support
=== 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.
=== 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 than copy and paste the existing rules. Moreover, for today's average user, the text only way is not the way to go. Even advanced users could benefit from the fact that they see the colors which they editing and perhaps the possible legend which would be generated for the map.
* Create a color and interval editor tool which should be able to create files which are compatible with G7:r.reclass, G7:r.colors, G7:v.colors and friends.
* The G7:r.colors `rules` parameter which now to enter values directly, instead of having them stored in the file, can have a button associated with it which would bring user to the manager/editor which would allow the true interactivity, color etc. and when finished, the rules would be trasfered as text back to the dialog `rules` parameter (exact GUI interface may differ, specification of features is more important and should be added here too).
* It might be also 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.
* Good API for the GUI-independent functionality can be beneficial in the future.
=== 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 r.sim.water can be used as a test case.
== For students ==
* If you have your own ideas, 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].
* Follow some good practices in your ideas and proposals:
* Stress why the project would be useful.
* Show that you know what how you will proceed. Make sure that what you propose is feasible.
* Be specific in the implementation (or at least as specific as you can).
* Explain how the final product will look like, how do we use it, perhaps, you can add some drawings (here to the wiki page)
* Explain how the idea relates to existing GRASS GIS functions and features.
* Don't include steps such as "install GRASS" or "compile GRASS libraries (on my machine)", you should do this before 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 struggle with it, consult at [http://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list].
* See also SUBMITTING files in source code.
* Be active on 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], implement some (smaller) features, or write some (simpler) GRASS module (and post it to mailing list) to show your willingness and abilities.
== Accepted proposals ==
''The template for this part is [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Accepted_Ideas here].''
''The student page with the tracking of the project should be child of this page, e.g. `GSoC/2014/TemporalGISAlgebra`. 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).''