[GRASS-dev] GRASS SoC ideas wiki

[Hamish]

Helena wrote:
> I have edited few things on the GRASS SoC wiki
> http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2011
> and added few items - please add yourself as mentor or
> co-mentor if you can help
> with any of the posted ideas.
> 
> Except for mentors, the Ideas page  page seems to be
> in a pretty good shape - perhaps we can remove the big "under
> construction" banner?

Hi,

thanks! yes, it looks good. I just make a few more edits as well and
removed the work-in-progress sign.

FYI I don't plan on being a primary mentor for any particular project
this year as I'll have my hands full being a floating co-mentor/admin on
all of OSGeo's accepted projects. I'll still be active of course, and if
there ends up being a project particularly relevant to me I'd consider
the role of a dedicated co-mentor on that. (I suspect Anne and
Wolf will do the same)


some notes on the ideas page:
 - no time to waste, student applications open in the next 48 hours!

 - v.surf.* break lines support: "Current implementations provide no
   support to specify locations of cliffs or faults" --not quite true,
   see v.surf.icw from addons & Ben D's recent journal publication.
     http://grass.osgeo.org/wiki/GRASS_AddOns#v.surf.icw

 - I think it's important to list language requirements for the various
   tasks, otherwise we'll get applications developing ideas to do things
   in GTK, Java, etc which are better known by the applicant, but not
   relevant to GRASS.

 - "Optimize OGSF (and NVIZ/wxNVIZ) to display large 3D point clouds with
   uninterupted tought speed"..   "tought"->"thought"?

 - "implement color management for 3D rasters : r3.colors" -> Not big enough
   for a whole summer project, would need to be combined with other tasks.

 - "Design GRASS toolboxes environment, see GRASS repository layout proposal
   for detailed information. This would also include general clean up and
   organization of existing GRASS modules in trunk and add-ons."
   -> We can't dump a student into such a contentious area without coming
   to some consensus on the design ourselves first. Personally I consider
   the breaking up of GRASS's 400 modules into a series of optional
   toolboxes to be a massive mistake. GEM already exists, but no one wants
   to use it, g.extention is at its core fundamentally a hack (I say as a
   coauthor), etc.--there's still a lot of maturing of ideas to do. The
   wiki addons page is getting rather long, but we aren't on the scale of
   needing something like CRAN yet..

 - "Design sophisticated Python scripting interface for GRASS". -> I don't
   get it. What is it? What would it do which python + grass.py doesn't
   already?


thanks,
Hamish