Changes between Version 17 and Version 18 of GSoC/2015

Timestamp:

Mar 3, 2015, 11:45:51 AM (9 years ago)

Author:

wenzeslaus

Comment:

improve Locations idea

GSoC/2015

@@ -212 +212 @@
  * Co-mentor: ?
 
-=== GRASS GIS locations created from public data ===
-
-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.
+=== GRASS GIS Locations created from public data ===
+
+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.
  * There are some datasets freely available such as OSM, US government data or some INSPIRE (see also: http://grasswiki.osgeo.org/wiki/Global_datasets).
  * 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.
  * Requirements on student:
-  * 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.
-  * Deep knowledge of GRASS is not necessary.
+  * 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.
+  * Deep knowledge of GRASS GIS is not necessary.
   * 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.
-  * Language requirements: Bourne shell scripting, Python
+  * Language requirements: Bourne shell scripting, Python (Python would the the primary tool used)
  * Mentor: ?
  * Co-mentor: ?
@@ -247 +247 @@
  * Several use cases should be explored and used as examples.
  * 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.
- * 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).
+ * 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).
  * Language requirements: Python, wxPython
  * Mentor: ?