| | 156 | |
| | 157 | === Web-based GUI for GRASS GIS === |
| | 158 | |
| | 159 | * This idea will consist in building a web application "WebGRASS" which allows to run GRASS modules on modern browsers. |
| | 160 | * The user interface for WebGRASS will be built using [http://www.webtoolkit.eu/wt Wt], Web Toolkit. |
| | 161 | * WT provides C++ API and python bindings (available on [https://github.com/wdu/pywt github]) for developing web widgets. |
| | 162 | * Each grass module is described by an XML file generated the module's ''--interface-description'' parameter, the xml file is then parsed to generate the Module Form interface. |
| | 163 | * Parsing of the xml file and generating tokens is already available in GRASS GIS. |
| | 164 | * The main User Interface will be composed by: |
| | 165 | * Auth-module (user log-in) |
| | 166 | * mapset-location wizard |
| | 167 | * map canvas (based on openlayers) |
| | 168 | * menu bar with same layout of grass desktop |
| | 169 | * toolbar with: |
| | 170 | - pan |
| | 171 | - query |
| | 172 | - zoom in - out - to bbox - to layer - to region |
| | 173 | - save to img mapcanvas |
| | 174 | - save display extent to region |
| | 175 | * Command line prompt (a GRASS shell based on IPython Notebook) |
| | 176 | * Security concerns |
| | 177 | * By default Web-GRASS is designed to allow access to trusted users. |
| | 178 | * Each user will be an UNIX user on the server with his own home. |
| | 179 | * The web-grass UI interface will be accessible through an opportune registration/auth/login framework. |
| | 180 | * The communication over the network will be encrypted using HTTPS. |
| | 181 | * The input parameters will be parsed and sanitized, this will be part of the UI itself, based on the [http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html GRASS command-line parsing] |
| | 182 | * Will be choice of deployment team to decide to adopt any 'Extra security layer'. This can be achieved using tools like: |
| | 183 | * [https://www.docker.io/ docker] |
| | 184 | * [https://linuxcontainers.org/ lxc] |
| | 185 | * [http://supervisord.org/ supervisors] |
| | 186 | * [http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds5/ulimit.htm ulimit] |
| | 187 | * Discussion on the grass-dev mailing-list [http://lists.osgeo.org/pipermail/grass-dev/2014-March/067665.html GRASS GIS Web UI] |
| | 188 | * Detailed [http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/massimo_di_stefano/5685265389584384 Idea description] |
| | 189 | * [wiki:GSoC/2014/WebGRASS page for more broad idea description including alternatives] (unfinished) |
| | 190 | * Language requirements: C++, Python |
| | 191 | * Mentor: ? |
| | 192 | * Co-Mentor: ? |
| | 193 | * Sample !PyWt implementation to call GRASS commands from a !PyWt web UI by [http://wiki.osgeo.org/wiki/User:Epifanio Massimo Di Stefano] |
| | 194 | * [https://github.com/epifanio/wgrass source code] |
| | 195 | |
| | 196 | === Improved Metadata for GRASS GIS === |
| | 197 | |
| | 198 | * During last years Google Summer of Code Matej Krejci developed ISO-based Metadata support for GRASS 7.1 [http://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS] |
| | 199 | * This project aims at continuing this work by: |
| | 200 | * Adding CSW-T support for saving and updating metadata in metadata catalogs (e.g. [http://geonetwork-opensource.org/ GeoNetwork] or [http://geonode.org/ GeoNode]). |
| | 201 | * Adding an option for fetching predefined metadata values from metadata catalog databases e.g.: keyword lists, points of contacts, ... or alternatively (for those who do not use Metadata catalogues) store such values in a DB (the backend used in GRASS GIS) |
| | 202 | * Adding support for temporal datasets (TGIS) |
| | 203 | * Adding functions for metadata export to other formats (e.g. PDF) |
| | 204 | * Fixing minor enhancements and bugs listed on http://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS |
| | 205 | * Compatibility and synergies with other GIS systems should be considered, especially QGIS, gvSIG and GDAL/OGR. |
| | 206 | * Requirements on student: |
| | 207 | * Familiarity with XML and UML |
| | 208 | * This project does not require deep knowledge of GRASS since metadata are (or can be) mostly independent on rest of the things. |
| | 209 | * Student must be proactive and consult the project with GRASS users from different countries (continents). |
| | 210 | * OWSLib is written in Python, in the OSGeo family pycsw is already using it (see http://geopython.github.io/pycsw-workshop/docs/advanced/advanced-exercises.html) |
| | 211 | * Mentor: ? |
| | 212 | * Co-mentor: ? |
| | 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. |
| | 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 | * 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. |
| | 219 | * Additional metadata must be generated too such as web pages and XMLs with links to provide access to these datasets. |
| | 220 | * This project should also prepare an infrastructure, so that in the future users can contribute their country-specific scripts. |
| | 221 | * Finally, the project would involve writing of a GUI interface integrated into wxGUI start/welcome screen which would offer download of the location. |
| | 222 | * Scripts should be usable as standalone scripts when downloaded separately (so user can download some fresh data or can import into an existing location). Compatibility with the [http://live.osgeo.org OSGeo Live] sampler DVD would be a major bonus. |
| | 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 | * 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. |
| | 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 |
| | 229 | * Mentor: ? |
| | 230 | * Co-mentor: ? |
| | 231 | |
| | 232 | |
