Changes between Version 24 and Version 25 of GSoC/2017
- Timestamp:
- Feb 11, 2017, 7:12:15 AM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GSoC/2017
v24 v25 70 70 * Requirements: Basic knowledge of GRASS GIS scripting and IPython/Jupyter Notebooks, Python, !JavaScript 71 71 * Mentor: Vaclav Petras 72 * Co-mentor: Massimo Di Stefano, Anna Petrasova72 * Potential co-mentors: Massimo Di Stefano, Pietro Zambelli 73 73 74 74 === Integration of PDAL into GRASS GIS === … … 79 79 * Optional (depending on time) or as a separate topic: v.external and `@PDAL` pseudo-mapset for point clouds 80 80 * Requirements: C, C++ 81 * Mentor: ?82 * Co-mentors: Vaclav Petras, Doug Newcomb81 * Mentor: Vaclav Petras 82 * Co-mentors: Doug Newcomb (non-coding part) 83 83 84 84 === Benchmarking framework for GRASS GIS === … … 88 88 * Sharing of interface and code with the existing testing framework needs to be addressed. 89 89 * See also https://github.com/jachym/grass-performace and wiki:GSoC/2014/TestingFrameworkForGRASS 90 * Mentor: ?91 * Co-mentor: Vaclav Petras90 * Mentor: Vaclav Petras 91 * Potential co-mentors: Soeren Gebbert, Jachym Cepicky 92 92 93 93 === GRASS GIS as a post-processing part of WebODM === … … 95 95 * Integrate GRASS GIS into WebODM for post-processing of point clouds and orthophotos. 96 96 * This will require development in the are of GRASS GIS command line (and/or Python) interface for standalone applications. These improvements need to be integrated into GRASS GIS for maintenance and re-usability purposes. 97 97 98 === v.in.osm enhancement === 98 99 … … 118 119 * Language requirements: Python, wxPython 119 120 * Mentor: ? 121 * Co-mentor: Vaclav Petras (coding part) 120 122 * With support from: Moritz Lennert (with limited time available, though) 121 123 … … 144 146 * Proposal must identify potential areas which need a higher level API and what features would the API provide in comparison to the current API (and when it would be just enough to extent the current API). 145 147 * Possible improvements include: 146 * Random access to raster values which supports all-in-memory approach and hides implementation details such as row-based storage and separate segmentation .148 * Random access to raster values which supports all-in-memory approach and hides implementation details such as row-based storage and separate segmentation (C version implemented in r70478). 147 149 * Unified access to a series of maps (list, group, spatio-temproal dataset) which hides potential improvements towards direct support of NetCDF series or Rasdaman. 148 150 * C++ interface leveraging C++ features such as operator overloading or support of STL algorithms. 149 151 * Bridging of C++ RAII and try-catch with GRASS GIS C API exit and optional memory cleaning must be addressed. 150 152 * Language requirements: C and C++ 151 * Mentor: ? 152 * Co-mentor: Vaclav Petras 153 * This idea needs extending and evaluating. 153 * Mentor: Vaclav Petras 154 * Potential co-mentor: Soeren Gebbert 155 * This idea needs extending and evaluating. A possible alternative is RCP interface in Python which also solves issues related to building persistent applications (e.g. GUIs) based on GRASS GIS libraries. 156 154 157 === Tools for generating unit tests from examples in the manual === 155 158 … … 158 161 159 162 * Language requirements: Python 160 * Mentor: ??? 163 * Mentor: Vaclav Petras 164 * Co-mentor: Soeren Gebbert 161 165 162 166 === Mapnik rendering engine for GRASS GIS === … … 184 188 * in this was separated parts of the GUI can be implemented in Qt separately 185 189 * Mentors: Martin Landa, Anna Petrasova, Vaclav Petras 186 * Similar project accepted : wiki:GSoC/2016/PyQtGUI190 * Similar project accepted in 2016 (wiki:GSoC/2016/PyQtGUI). This project should move it several steps further. 187 191 188 192 === GRASS GIS 3D viewer NVIZ module independent of the main GUI === … … 217 221 * Deep knowledge of GRASS GIS is not necessary. 218 222 * 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. 219 * Language requirements: Bourne shell scripting, Python (Python would the the primary tool used)223 * Language requirements: Python (Python would the the primary tool used), Bash, wxPython (basics) 220 224 * Mentor: ? 221 * Co-mentor: ?225 * Co-mentor: Vaclav Petras (coding and GUI integration part) 222 226 223 227 === Integration of v.profile into GUI profiling tool === 224 228 225 229 Current GUI profile tool supports creation of profiles of raster maps. It serves as a visualisation frontend to r.profile. Sometimes it is necessary to integrate into profile information on some objects (river, road, observation point etc.) that are provided as vector objects. Such functionality is provided by v.profile add-on (planned to be moved from add-ons to main modules), still any visualisation tool is lacking. Thus as a part of SOC existing profiling tool could be extended to include also vector profiling capabilities. This SOC requires basic knowledge of Python and will provide introduction into wxPython program development. 226 * Integration of v.profile should provide support of:230 * Integration of v.profile (addon module) should provide support of: 227 231 * displaying vector points as symbols by their Z coordinate / attribute value OR on a selected raster profile line 228 232 * displaying vector line crossing places as vertical lines 229 233 * displaying labels next to symbols or at X axis 234 * This can be extended by integrating also v.profile.points which is a different way of profiling vector maps. 230 235 * Requirements: Python, wxPython 231 236 * Mentor: ? 232 * Co-mentors: Māris Nartišs, ?237 * Co-mentors: Māris Nartišs, Vaclav Petras (v.profile.points part) 233 238 234 239 === Implement cutline generation === … … 266 271 * If you get stuck with the setup, feel free to consult the [http://lists.osgeo.org/listinfo/grass-user grass-user mailing list]. 267 272 * Familiarize yourself with wiki:Submitting rules. 268 * 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. 273 * 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. You should start even before you apply to GSoC. 274 * Also note that fixing existing bugs and/or implementing enhancements will be a part of student evaluation. 269 275 270 276 * 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].
