GRASS Google Summer of Code 2014

About

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

Ideas

Some bigger ideas may have their own pages at Trac Wiki, so you can link them here. You can also have a look at ideas from previous years (​2007, ​2008, ​2009, ​2010, ​2011, ​2012 ​2013) and projects from previous years.

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)

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
• Student: Vaclav Petras
• Mentor: Soeren Gebbert

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. 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).