Changes between Initial Version and Version 1 of GSoC/2017


Ignore:
Timestamp:
Jan 22, 2017, 3:24:49 AM (4 years ago)
Author:
martinl
Comment:

copy from last year

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2017

    v1 v1  
     1
     2{{{
     3#!html
     4<!-- direct usage of HTML enables to use the big @ characters at the same line as images -->
     5<!-- derived from the HTML taken from GRASS User Mediawiki -->
     6<!-- needs to be changed every year (GSoC link and picture) -->
     7<p>
     8<a href="http://grass.osgeo.org" rel="nofollow">
     9<img alt="Grasslogo vector small.png" src="/grass/raw-attachment/wiki/GSoC/2014/Grasslogo_vector_small.png" width="110" height="123" />
     10</a>
     11 <font size="+3"> @ </font>
     12<a href="http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016" rel="nofollow">
     13<img alt="500px-GSoC2016Logo.jpg​" src="/grass/raw-attachment/wiki/GSoC/2016/500px-GSoC2016Logo.jpg"/>
     14</a>
     15<font size="+3"> @ </font>
     16<a href="http://www.osgeo.org" rel="nofollow">
     17<img alt="OSGeo 220pix.png" src="/grass/raw-attachment/wiki/GSoC/2014/OSGeo_220pix.png" width="262" height="117" /></a>
     18</p>
     19}}}
     20
     21
     22= GRASS Google Summer of Code 2016 =
     23
     24[[TOC]]
     25
     26
     27== About ==
     28
     29 * [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016 The OSGeo GSoC 2016 main page]
     30 * [https://summerofcode.withgoogle.com/ Official GSoC 2016 page at Google]
     31
     32== Ideas ==
     33
     34''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.''
     35
     36If 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].
     37
     38''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],
     39[http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2009#Ideas 2009], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2010#Ideas 2010],
     40[http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2011#Ideas 2011], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012#Ideas 2012],
     41[http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Ideas 2013], [wiki:/GSoC/2014 2014], [wiki:/GSoC/2015 2015]) which have not yet been implemented.
     42You can also look at accepted GRASS GSoC [wiki:GSoC projects from previous years] for an idea of scope.''
     43
     44''Include "GRASS GIS" in the title of our idea to easily distinguish ideas and projects inside OSGeo.''
     45
     46''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`).''
     47
     48=== Mapnik rendering engine for GRASS GIS ===
     49
     50 * Mapnik is a powerful rendering engine written in C++ with Python bindings.
     51 * The project tend to add Mapnik engine as alternative backend to [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
     52 * The implementation will have most of the capabilities of actual [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
     53 * The plugin will be able to create different format of images (PNG, PDF, etc)
     54 * The plugin will be able to export XML Mapnik file
     55 * A similar implementation is [https://github.com/springmeyer/quantumnik/ quantumnik]
     56 * Language requirements: Python
     57 * Mentor: Luca Delucchi
     58 * Co-Mentor: Martin Landa
     59
     60=== Complete basic cartography suite in GRASS GIS wxGUI Map Display ===
     61
     62 * 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 in case it is not possible to implement everything during summer.
     63 * first phase:
     64  * store legend, scale bar, north arrow and text (and others if added) in workspace (#2369)
     65  * add units to legend (optionally also title) as parameter
     66  * possibility to add any image (as in animation tool), use cases: logo/watermark, workaround for overview maps
     67  * disable rendering when adding multiple layers into layer manager using ''Add multiple...'' (disabled rendering when loading workspace already implemented in r63319)
     68  * determine map window size without the need to change map display size manually when loading workspace (currently there is a bug, when loading workspace, map display has correct size but map window is smaller and one must resize the window to get the right size of map window)
     69 * second phase:
     70  * support map units in scale bar, not only meters
     71  * allow user to set the length of scale bar (in map units)
     72  * manual breaks/ticks for legend (it is possible to set number of breaks/ticks but the values are not rounded), additional feature would be an option for automatic breaks/ticks every ten, hundred, ...
     73  * legend background (currently the legend has transparent background), additional features include rounded corners, border and opacity settings
     74  * general shapes
     75   * can be implemented using `d.*` commands (e.g. `d.graph`) or wxPython or both (wxPython might be easier for interactivity, `d.*` commands for scripting)
     76   * use cases: workaround missing background of legend or text, manual marking of special points
     77  * include map-display-like object
     78   * useful for overview maps (insets) or histograms
     79   * would be represented as image but the image would be dynamically generated
     80   * controlled using something like nested map display
     81   * 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
     82   * the important feature is the user does not have to create an intermediate file
     83   * Simple Layer Manager classes can be used to manage layers in the additional/nested map display
     84 * third phase:
     85  * implement vector legend:
     86   * 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).
     87   * May get complicated with (enhancements of) vector thematic mapping
     88  * enhance `d.vect.thematic`
     89  * make `d.text`, `d.graph`, `d.erase` and perhaps other existing `d.*` modules accessible from wxGUI
     90  * implement module which can parametrize workspace (similarly as `g.gui.animation` is doing for 3D View) and render it with different maps
     91   * if the implementation would be wxPython free (ideal option) then it would have to translate some wxPython/wxGUI specific things to plain `d.*` commands
     92   * this can be also implemented as a script generator (rather than workspace renderer)
     93   * it should work as a simple automatic map ("atlas") generator and should accept also time series as the input
     94  * general system and (GUI) manager for additional object on map display
     95   * should support multiple legends and scale bars
     96   * should include general shapes
     97   * should work with any `d.*` commands, e.g. `d.histogram`
     98 * It would be great to make as much things as possible to work also in 3D Views (wxNVIZ).
     99 * Thorough (manual) testing on different platforms and version of wxPython is needed (by student or mentors).
     100 * See also:
     101  * [wiki:GSoC/2014#GRASSGISMapdisplaydecorationsenhancements map decorations idea from last year]
     102  * [wiki:GSoC/2014#VectorlegendforGRASSGIS vector legend idea from last year]
     103  * #2582 (implement `d.vect.thematic2` addon module features in `d.vect.thematic` core module)
     104  * [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072918.html grass-dev future of thematic mapping in GRASS]
     105  * [http://lists.osgeo.org/pipermail/grass-dev/2010-March/049414.html grass-dev future thematic cartography in GRASS]
     106  * [wiki:GSoC/2014#ColortablemanagementGRASSGISwxGUI slightly related color tables idea from last year]
     107  * #2080 (changing properties of scale bar or legend)
     108 * Language requirements: Python, wxPython, C and OpenGL will be needed for some parts
     109 * Co-mentors: Anna Petrasova, Helena Mitasova, Martin Landa, Vaclav Petras
     110 * Accepted student: Adam Laza
     111 * Accepted project page: wiki:GSoC/2016/BasicCartographySuiteInGRASS
     112
     113
     114=== Generalized GUI code for Qt-based GUI ===
     115
     116 * 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
     117 * Qt is used more and more, QGIS uses Qt
     118 * the current GUI code (wxGUI) often lacks proper design and is hard to maintain, addition of new features requires hacks or refactoring
     119 * a new fresh implementation of GUI is need
     120 * 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
     121  * 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)
     122  * this will also show that the logic is actually from the graphical representation
     123  * this avoids dropping wxGUI at the point when the new doesn't have all the features of the new one
     124  * in this was separated parts of the GUI can be implemented in Qt separately
     125 * Mentors: Martin Landa, Anna Petrasova, Vaclav Petras
     126 * Similar project accepted: wiki:GSoC/2016/PyQtGUI (student: Ondrej Pesek)
     127=== GRASS GIS 3D viewer NVIZ module independent of the main GUI ===
     128
     129 * 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.
     130 * 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.
     131 * 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).
     132 * The command line interface should be similar to `m.nviz.image` module but should also accept wxGUI workspace file.
     133 * Some refactoring will be needed to uncouple GUI controls (now part of Layer Manager) and the rendering
     134  * 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
     135  * usage in `g.gui.animation` could be considered too
     136  * having a Python API might be quite advantageous for scripting (although `m.nviz.image` solves most of the problems)
     137 * 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.
     138 * Language requirements: Python, wxPython, (C and OpenGL shouldn't be necessary)
     139 * Other requirements: basic software design patterns and GUI programming experience
     140
     141=== Web-based GUI for GRASS GIS ===
     142
     143 * This idea will consist in building a web application "WebGRASS" which allows to run GRASS modules on modern browsers.
     144 * The user interface for WebGRASS will be built using [http://www.webtoolkit.eu/wt Wt], Web Toolkit.
     145 * WT provides C++ API for developing web widgets.
     146 * 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.
     147 * Parsing of the xml file and generating tokens is already available in GRASS GIS.
     148 * The main User Interface will be composed by:
     149  * Auth-module (user log-in)
     150  * mapset-location wizard
     151  * map canvas (based on openlayers)
     152  * menu bar with same layout of grass desktop
     153  * toolbar with:
     154    - pan
     155    - query
     156    - zoom in - out - to bbox - to layer -  to region
     157    - save to img mapcanvas
     158    - save display extent to region
     159 * Command line prompt (a GRASS shell based on IPython Notebook)
     160 * Security concerns
     161  * By default Web-GRASS is designed to allow access to trusted users.
     162  * Each user will be an UNIX user on the server with his own home.
     163  * The web-grass UI interface will be accessible through an opportune registration/auth/login framework.
     164  * The communication over the network will be encrypted using HTTPS.
     165  * 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]
     166  * Will be choice of deployment team to decide to adopt any 'Extra security layer'. This can  be achieved using tools like: 
     167   * [https://www.docker.io/ docker]
     168   * [https://linuxcontainers.org/ lxc]
     169   * [http://supervisord.org/ supervisors]
     170   * [http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds5/ulimit.htm ulimit]
     171 * Discussion on the grass-dev mailing-list [http://lists.osgeo.org/pipermail/grass-dev/2014-March/067665.html GRASS GIS Web UI]
     172 * Detailed [http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/massimo_di_stefano/5685265389584384 Idea description]
     173 * [wiki:GSoC/2014/WebGRASS page for more broad idea description including alternatives] (unfinished)
     174 * Language requirements: C++, HTML5, Javascript
     175 * Mentor: Rashad Kanavath
     176 * Co-Mentor: ?
     177 * Sample !PyWt implementation to call GRASS commands from a !PyWt web UI by [http://wiki.osgeo.org/wiki/User:Epifanio Massimo Di Stefano]
     178  * [https://github.com/epifanio/wgrass source code]
     179
     180=== GRASS GIS Locations created from public data ===
     181
     182The 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.
     183 * There are some datasets freely available such as OSM, US government data or some INSPIRE (see also: http://grasswiki.osgeo.org/wiki/Global_datasets).
     184 * 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.
     185 * Additional metadata must be generated too such as web pages and XMLs with links to provide access to these datasets.
     186 * This project should also prepare an infrastructure, so that in the future users can contribute their country-specific scripts.
     187 * Finally, the project would involve writing of a GUI interface integrated into wxGUI start/welcome screen which would offer download of the location.
     188 * 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).
     189 * 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.
     190 * Original metadata should be preserved, distributed with the data and used to create a description in the download side and in the GUI.
     191 * Requirements on student:
     192  * 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.
     193  * Deep knowledge of GRASS GIS is not necessary.
     194  * 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.
     195  * Language requirements: Bourne shell scripting, Python (Python would the the primary tool used)
     196 * Mentor: ?
     197 * Co-mentor: ?
     198
     199=== Additional segmentation algorithms for i.segment ===
     200
     201GRASS GIS has the [https://grass.osgeo.org/grass70/manuals/i.segment.html i.segment] which provides the possibility to segment an image into objects. This is a basic step in object-based image analysis (OBIA). Currently, the module only provides one segmentation algorithm: region-growing. Many others exist: mean-shift, split-window, watershed, etc. The code of i.segment was structured in a way that allows addition of other algorithms. The core of the GSoC project would thus be to add a series of these algorithms. In addition, the current implementation only uses distance within the multidimensional space of all input bands as the criteria whether to merge segments or not. Adding shape as an additional merge criteria would be helpful. A first implementation exists in the code, but is not functional as such. If time permits, the student should implement this feature.
     202Special care should be taken for the whole project to code as efficiently as possible, i.e. to make the code run in reasonable time, even for very large images.
     203
     204The project implies coding in C, with extensive use of the GRASS GIS raster libraries, but with most of the framework already in place.
     205
     206 * Co-mentors: Moritz Lennert, Markus Metz
     207
     208=== v.in.osm enhancement ===
     209
     210OpenStreetMap is a powerfull dataset. A module to import these data is neeeded. 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:
     211 * [http://wiki.openstreetmap.org/wiki/Osm2pgsql osm2pgsql] using PostgreSQL/PostGIS
     212 * ogr library through [http://www.gdal.org/drv_osm.html OSM format]
     213 * [http://imposm.org/ impoosm] version 2 is written in Python, version 3 is written in [https://golang.org/ go language]
     214 * could be possible to develop a C library to convert OSM data directly inside GRASS
     215
     216* Language requirements: Python, C
     217* Co-mentors: Luca Delucchi, Pietro Zambelli
     218 
     219== Tips for students ==
     220
     221 * 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].
     222 * 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.
     223 * Follow some good practices in your ideas and proposals:
     224  * Stress why the project would be useful.
     225  * 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.
     226  * Be specific in the implementation (or at least as specific as you can).
     227  * 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)
     228  * Explain how the idea relates to existing GRASS GIS functions, features, and needs.
     229  * 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.
     230 * Compile GRASS GIS 7 (trunk) from source and prepare environment for development:
     231  * See links appropriate for you at [http://grass.osgeo.org/development/how-to-start/].
     232  * If you get stuck with the setup, feel free to consult the [http://lists.osgeo.org/listinfo/grass-user grass-user mailing list].
     233  * Familiarize yourself with wiki:Submitting rules.
     234 * 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.
     235
     236 * 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].