Changes between Version 11 and Version 12 of GSoC/2017


Ignore:
Timestamp:
Jan 25, 2017, 2:52:00 PM (4 years ago)
Author:
wenzeslaus
Comment:

put new topics to the front

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2017

    v11 v12  
    4646''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/2017/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2017/CoolGRASSProject`).''
    4747
    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 === Generalized GUI code for Qt-based GUI ===
    61 
    62  * 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
    63  * Qt is used more and more, QGIS uses Qt
    64  * the current GUI code (wxGUI) often lacks proper design and is hard to maintain, addition of new features requires hacks or refactoring
    65  * a new fresh implementation of GUI is need
    66  * 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
    67   * 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)
    68   * this will also show that the logic is actually from the graphical representation
    69   * this avoids dropping wxGUI at the point when the new doesn't have all the features of the new one
    70   * in this was separated parts of the GUI can be implemented in Qt separately
    71  * Mentors: Martin Landa, Anna Petrasova, Vaclav Petras
    72  * Similar project accepted: wiki:GSoC/2016/PyQtGUI (student: Ondrej Pesek)
    73 
    74 === GRASS GIS 3D viewer NVIZ module independent of the main GUI ===
    75 
    76  * 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.
    77  * 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.
    78  * 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).
    79  * The command line interface should be similar to `m.nviz.image` module but should also accept wxGUI workspace file.
    80  * Some refactoring will be needed to uncouple GUI controls (now part of Layer Manager) and the rendering
    81   * 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
    82   * usage in `g.gui.animation` could be considered too
    83   * having a Python API might be quite advantageous for scripting (although `m.nviz.image` solves most of the problems)
    84  * 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.
    85  * Language requirements: Python, wxPython, (C and OpenGL shouldn't be necessary)
    86  * Other requirements: basic software design patterns and GUI programming experience
    87 
    88 === GRASS GIS Locations created from public data ===
    89 
    90 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: 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.
    91  * There are some datasets freely available such as OSM, US government data or some INSPIRE (see also: http://grasswiki.osgeo.org/wiki/Global_datasets).
    92  * 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.
    93  * Additional metadata must be generated too such as web pages and XMLs with links to provide access to these datasets.
    94  * This project should also prepare an infrastructure, so that in the future users can contribute their country-specific scripts.
    95  * Finally, the project would involve writing of a GUI interface integrated into wxGUI start/welcome screen which would offer download of the location.
    96  * 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).
    97  * 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.
    98  * Original metadata should be preserved, distributed with the data and used to create a description in the download side and in the GUI.
    99  * Requirements on student:
    100   * 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.
    101   * Deep knowledge of GRASS GIS is not necessary.
    102   * 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.
    103   * Language requirements: Bourne shell scripting, Python (Python would the the primary tool used)
    104  * Mentor: ?
    105  * Co-mentor: ?
    10648
    10749=== Additional functionality for running GRASS GIS modules in Jupyter Notebook ===
     
    174116* Language requirements: Python
    175117* Mentor: Luca Delucchi
    176  
     118
     119=== Mapnik rendering engine for GRASS GIS ===
     120
     121 * Mapnik is a powerful rendering engine written in C++ with Python bindings.
     122 * The project tend to add Mapnik engine as alternative backend to [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
     123 * The implementation will have most of the capabilities of actual [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
     124 * The plugin will be able to create different format of images (PNG, PDF, etc)
     125 * The plugin will be able to export XML Mapnik file
     126 * A similar implementation is [https://github.com/springmeyer/quantumnik/ quantumnik]
     127 * Language requirements: Python
     128 * Mentor: Luca Delucchi
     129 * Co-Mentor: Martin Landa
     130
     131=== Generalized GUI code for Qt-based GUI ===
     132
     133 * 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
     134 * Qt is used more and more, QGIS uses Qt
     135 * the current GUI code (wxGUI) often lacks proper design and is hard to maintain, addition of new features requires hacks or refactoring
     136 * a new fresh implementation of GUI is need
     137 * 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
     138  * 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)
     139  * this will also show that the logic is actually from the graphical representation
     140  * this avoids dropping wxGUI at the point when the new doesn't have all the features of the new one
     141  * in this was separated parts of the GUI can be implemented in Qt separately
     142 * Mentors: Martin Landa, Anna Petrasova, Vaclav Petras
     143 * Similar project accepted: wiki:GSoC/2016/PyQtGUI (student: Ondrej Pesek)
     144
     145=== GRASS GIS 3D viewer NVIZ module independent of the main GUI ===
     146
     147 * 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.
     148 * 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.
     149 * 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).
     150 * The command line interface should be similar to `m.nviz.image` module but should also accept wxGUI workspace file.
     151 * Some refactoring will be needed to uncouple GUI controls (now part of Layer Manager) and the rendering
     152  * 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
     153  * usage in `g.gui.animation` could be considered too
     154  * having a Python API might be quite advantageous for scripting (although `m.nviz.image` solves most of the problems)
     155 * 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.
     156 * Language requirements: Python, wxPython, (C and OpenGL shouldn't be necessary)
     157 * Other requirements: basic software design patterns and GUI programming experience
     158
     159=== GRASS GIS Locations created from public data ===
     160
     161The 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.
     162 * There are some datasets freely available such as OSM, US government data or some INSPIRE (see also: http://grasswiki.osgeo.org/wiki/Global_datasets).
     163 * 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.
     164 * Additional metadata must be generated too such as web pages and XMLs with links to provide access to these datasets.
     165 * This project should also prepare an infrastructure, so that in the future users can contribute their country-specific scripts.
     166 * Finally, the project would involve writing of a GUI interface integrated into wxGUI start/welcome screen which would offer download of the location.
     167 * 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).
     168 * 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.
     169 * Original metadata should be preserved, distributed with the data and used to create a description in the download side and in the GUI.
     170 * Requirements on student:
     171  * 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.
     172  * Deep knowledge of GRASS GIS is not necessary.
     173  * 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.
     174  * Language requirements: Bourne shell scripting, Python (Python would the the primary tool used)
     175 * Mentor: ?
     176 * Co-mentor: ?
     177
    177178== Tips for students ==
    178179