| 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: ? |
| 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 | |
| | 161 | 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. |
| | 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 | |
