GRASS SoC Ideas 2011: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
Line 80: Line 80:
* offer also (optional) "conventional" GUI layout: For some users, the current approach of separate windows (SDI) leads to a '''windows flooding'''. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen:  [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see [[WxGUI#Layout]].
* offer also (optional) "conventional" GUI layout: For some users, the current approach of separate windows (SDI) leads to a '''windows flooding'''. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen:  [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see [[WxGUI#Layout]].
* Add WMS and/or TiledMapService layer support for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response.
* Add WMS and/or TiledMapService layer support for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response.
* ''Your idea here''
'''Willing to Mentor:''' (''your name here'')


=== Raster ===
=== Raster ===
* ''Your idea here''
'''Willing to Mentor:''' (''your name here'')


=== Vector ===
=== Vector ===
* ''Your idea here''
'''Willing to Mentor:''' (''your name here'')


=== Imagery ===
=== Imagery ===
* ''Your idea here''
'''Willing to Mentor:''' (''your name here'')


=== Other ===
=== Other ===
* ''Your idea here''
'''Willing to Mentor:''' (''your name here'')


== Guidelines for Students ==
== Guidelines for Students ==

Revision as of 11:26, 19 March 2011

About

This is the GRASS page for Google Summer of Code 2011. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:

Timeline

See GSoC timeline

  • Mentoring organization applications open (March 11)
  • Accepted mentoring organizations announced (March 18)
  • Interested students should initiate preliminary discussions with projects (March 18-27)
  • Student applications open (March 28)
  • Deadline for student's applications (April 8)
Registering your application early (before the deadline) allows us to give you feedback for revisions before the final deadline, enhancing your proposal and thus giving you a better chance of success.
  • Mentor assignments and application reviews deadline (April 22)
  • Accepted proposals announced (April 25)
  • Community bonding time (getting to know the students)
  • Work Begins (May 23)
  • Midterm evaluation (July 11-15)
  • Pencils down! (August 15)
  • Final evaluations submitted to Google (August 22)
  • Final results of GSoC 2011 announced (August 29)
  • Students can begin submitting required code samples to Google (August 30)

Required Steps

  • List ideas
  • Assign Mentors to Ideas
  • Notify OSGeo
  • Mentors evaluate student applications
  • Accepted students announced
  • Create directory structure in the GRASS add-ons SVN for projects and setup access for students
    • Students must read and post agreement to RFC2 to the grass-psc mailing list to gain SVN access
    • Create a Wiki page for each accepted project, to be used as a progress reporting tool
  • Coding begins...
  • Students and mentors: Complete the Mid-term survey
  • Final commit and packaging for Google

Ideas

  • Also review ideas from 2007, 2008, 2009, and 2010 which are still open.
  • Project ideas of your own are also most welcome.

wxGUI

  • offer also (optional) "conventional" GUI layout: For some users, the current approach of separate windows (SDI) leads to a windows flooding. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: example 1 and example 2. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see WxGUI#Layout.
  • Add WMS and/or TiledMapService layer support for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response.
  • Your idea here

Willing to Mentor: (your name here)

Raster

  • Your idea here

Willing to Mentor: (your name here)

Vector

  • Your idea here

Willing to Mentor: (your name here)

Imagery

  • Your idea here

Willing to Mentor: (your name here)

Other

  • Your idea here

Willing to Mentor: (your name here)

Guidelines for Students

How do you maximize your chances of getting picked? First read the Google SoC FAQ. Then talk to us about your idea. Try emailing our dev-mailing list, or come and talk to us in IRC (#grass). You can also reach the mentors directly by emailing:

Getting started with GRASS coding

  • The source code is maintained in a SVN server which is easy to browse
Please review the SUBMITTING files there for our coding standards.
See also the development section of the GRASS user's wiki

Accepted Ideas