Changes between Version 4 and Version 5 of GSoC/2017


Ignore:
Timestamp:
Jan 22, 2017, 3:28:55 AM (7 years ago)
Author:
martinl
Comment:

accepted projects removed

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2017

    v4 v5  
    5858 * Co-Mentor: Martin Landa
    5959
    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 
    11460=== Generalized GUI code for Qt-based GUI ===
    11561
     
    12571 * Mentors: Martin Landa, Anna Petrasova, Vaclav Petras
    12672 * Similar project accepted: wiki:GSoC/2016/PyQtGUI (student: Ondrej Pesek)
     73
    12774=== GRASS GIS 3D viewer NVIZ module independent of the main GUI ===
    12875
     
    13885 * Language requirements: Python, wxPython, (C and OpenGL shouldn't be necessary)
    13986 * 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]
    17987
    18088=== GRASS GIS Locations created from public data ===
     
    196104 * Mentor: ?
    197105 * Co-mentor: ?
    198 
    199 === Additional segmentation algorithms for i.segment ===
    200 
    201 GRASS 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.
    202 Special 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 
    204 The 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
    207106
    208107=== v.in.osm enhancement ===