Changes between Version 17 and Version 18 of GSoC/2015
- Timestamp:
- 03/03/15 11:45:51 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GSoC/2015
v17 v18 212 212 * Co-mentor: ? 213 213 214 === GRASS GIS locations created from public data ===215 216 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: 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.214 === GRASS GIS Locations created from public data === 215 216 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. 217 217 * There are some datasets freely available such as OSM, US government data or some INSPIRE (see also: http://grasswiki.osgeo.org/wiki/Global_datasets). 218 218 * 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. … … 223 223 * Original metadata should be preserved, distributed with the data and used to create a description in the download side and in the GUI. 224 224 * Requirements on student: 225 * Basic knowledge of GRASS scripting, wxPython, HTML/XML, and UNIX is needed. Some understanding of downloading and online protocols will be necessary for data acquisition.226 * Deep knowledge of GRASS is not necessary.225 * 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. 226 * Deep knowledge of GRASS GIS is not necessary. 227 227 * 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. 228 * Language requirements: Bourne shell scripting, Python 228 * Language requirements: Bourne shell scripting, Python (Python would the the primary tool used) 229 229 * Mentor: ? 230 230 * Co-mentor: ? … … 247 247 * Several use cases should be explored and used as examples. 248 248 * It would be good to consider (at least for the sake of real use case) turning some existing parts or wxGUI into plugins, e.g. vdigit, rdigit, iclass or various plots. 249 * Bonus task is to extend `g.extension` in the way that it supports local source code (#1652) and individual extensions as source code in GitHub (might be almost possible now using Subversion).249 * Bonus task is to extend `g.extension` in the way that it supports local source code (#1652) and individual extensions as source code in !GitHub (might be almost possible already using Subversion but on the level of the whole repository, not individual modules). 250 250 * Language requirements: Python, wxPython 251 251 * Mentor: ?