Changes between Version 2 and Version 3 of GSoC/2015


Ignore:
Timestamp:
Feb 10, 2015, 6:38:44 PM (5 years ago)
Author:
wenzeslaus
Comment:

New easy-to-use CLI; Tips for students; follow OSGeo rule to include project name in the title

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2015

    v2 v3  
    3030''Post your ideas here or to the [http://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list] if you want to discuss them more. To edit this wiki, you need to [https://trac.osgeo.org/grass/login login] with an [http://www.osgeo.org/osgeo_userid OSGeo Userid]; read also some [wiki:TracLinks help] for using trac.''
    3131
     32If you are a student you can suggest an new idea or pick up an existing one in any case write about it to [http://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list].
     33
    3234''You are invited as well to have a close look at (and re-suggest!) ideas from previous years ([http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2007 2007], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2008#Ideas 2008],
    3335[http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2009#Ideas 2009], [http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2010#Ideas 2010],
     
    3638You can also look at accepted GRASS GSoC [wiki:GSoC projects from previous years] for an idea of scope.''
    3739
    38 ''Some bigger ideas may have their own pages, so you can link them here. The pages can be either independent if the page already exists (e.g. `wxGUIDevelopment/SingleWindow`), or more preferably supbages of this page if the idea is (re-)developed for this GSoC. In the later case, use the word "idea" in the page name to distinguish the idea page (e.g. `GSoC/2015/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2015/CoolGRASSProject`).''
     40''Include "GRASS GIS" in the title of our idea to easily distinguish ideas and projects inside OSGeo.''
    3941
    40 === Mapnik rendering engine ===
    41  * Mapnik is a powerfull rendering engine written in C++ with Python bindings.
     42''Some bigger ideas may have their own pages, so you can link them here. The pages can be either independent if the page already exists (e.g. `wxGUIDevelopment/SingleWindow`), or more preferably subpages of this page if the idea is (re-)developed for this GSoC. In the later case, use the word "idea" in the page name to distinguish the idea page (e.g. `GSoC/2015/CoolGRASSProjectIdea`) from the possible student project page (e.g. `GSoC/2015/CoolGRASSProject`).''
     43
     44=== Mapnik rendering engine for GRASS GIS ===
     45
     46 * Mapnik is a powerful rendering engine written in C++ with Python bindings.
    4247 * The project tend to add Mapnik engine as alternative backend to [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
    4348 * The implementation will have most of the capabilities of actual [http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer WxGUI Cartographic Composer]
     
    4853 * Mentor: Luca Delucchi
    4954 * Co-Mentor: ?
     55
     56=== New easy-to-use command line interface for GRASS GIS ===
     57
     58 * GRASS GIS requires GRASS GIS Database, Location and Mapset to be set up to maintain data consistency, efficiency and security. Unfortunately, this is cumbersome when GRASS GIS is not the primary tools one is using. There are different workarounds for calling GRASS modules without starting GRASS explicitly, or running GRASS in a batch mode. However, none of these allows one to skip the database setup phase. This leads to the need for constant reimplementing of setup, import and export steps in various environments including user scripts (Bash, Python, R), QGIS Processing, gvSIG/SEXTANTE, uDig/JGrassTools and all the web/server/cloud tools which use GRASS GIS as a processing backend.
     59 * GRASS GIS itself can make it easier for the callers (at least in most cases) by implementing an interface which would allow to use GRASS GIS modules without explicit dealing with GRASS GIS database.
     60 * The command line call using the proposed interface would look like this:
     61
     62{{{
     63grass run r.slope.aspect elevation=file://.../elevation.tiff aspect=file://...aspect.tiff
     64grass run r.lake elevation=some/file.tiff water_level=10 lake=some/new/file.tiff coordinates=100,520
     65}}}
     66
     67 * The `grass` command would have to parse the command line, find the files which should be maps (either using `file://` or perhaps anything would work) and import/export/link them, and then call the actual command.
     68 * The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import.
     69 * The output maps could be be also linked (external) with projection same as input which is should be faster then export.
     70 * Ideally this should work also with PostGIS and databases provided through GDAL/OGR.
     71 * The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used).
     72 * This project should also contain a [https://github.com/qgis/QGIS QGIS] Processing part.
     73  * Since QGIS Processing is one of the reasons for this interface, implementing is a crucial use case which should be tested from the very beginning a with QGIS Processing implementation, the interface would be used right away.
     74  * Alternatively, another project or more than one project can be in this part.
     75  * Title should change according to decisions made about this part.
     76 * Proposal should discuss how advanced things such raster algebra, multi-map inputs and outputs, temporal framework, cartography and visualization tools will work.
     77 * The system behind the interface will be inherently fragile, so it is necessary to write large amount of tests which would check different combinations of data types and projections.
     78 * Bonus task would be to find/implement a way to run Python code easily in case `grass` is called from Python (`grass python -c "print('...')"` is a good start).
     79 * Language requirements: Python (both GRASS GIS startup scripts and QGIS Processing are in Python)
     80 * See also #2579 and [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072979.html grass-dev QGIS Processing & GRASS (January 2015)], #2424, [http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly Working with GRASS without starting it explicitly]
     81 * Mentor for the GRASS GIS part: Vaclav Petras
     82 * Mentor for the QGIS part: ?
     83 * Mentor for the <insert other OSGeo project> part: ?
     84 * Co-mentors (e.g. PostGIS connection part): ?
     85
     86
     87== Tips for students ==
     88
     89 * If you have your own ideas we encourage you to propose them. Explain them on the [http://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list].
     90 * If you like some idea here or from previous yeas, write about it on [http://lists.osgeo.org/listinfo/grass-dev grass-dev mailing list] and any ideas of your own which could improve it.
     91 * Follow some good practices in your ideas and proposals:
     92  * Stress why the project would be useful.
     93  * Show that you know how you will proceed. That is, make sure that you can demonstrate that the proposal is feasible in the given time frame.
     94  * Be specific in the implementation (or at least as specific as you can).
     95  * Explain what the final product will look like and how it will work. Perhaps you can add some drawings or mock-ups. (here in a wiki page)
     96  * Explain how the idea relates to existing GRASS GIS functions, features, and needs.
     97  * Do not include steps such as "install GRASS", "compile GRASS libraries (on my machine)", "read about the API". You should do this before applying to GSoC.
     98 * Compile GRASS GIS 7 (trunk) from source and prepare environment for development:
     99  * See links appropriate for you at [http://grass.osgeo.org/development/how-to-start/].
     100  * If you get stuck with the setup, feel free to consult the [http://lists.osgeo.org/listinfo/grass-user grass-user mailing list].
     101  * Familiarize yourself with wiki:Submitting rules.
     102 * 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.
     103
     104 * 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_2015_Ideas OSGeo GSoc Ideas page].
     105
     106