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?
Helena
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
Hi,
2011/3/27 Hamish <hamish_b@yahoo.com>:
- "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
This is right.
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..
Discussion has been open by Jarek some time ago. (...) I really don't
think that "it would be a massive mistake", moreover I think it would
be "massive mistake" not organize currently available modules in trunk
+ addons to something more readable for GRASS users. Just my point of
view, I believe I am not alone in the GRASS community (feel free to
response). Anyway I will remove this idea from GSoC for now.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Sun, Mar 27, 2011 at 8:05 AM, Hamish <hamish_b@yahoo.com> wrote:
...
- "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.
Why?
GEM already exists, but no one wants to use it,
.. because it is overkill (since some lines of script to almost the same).
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..
For sure the *easy* integration of extra functionality is wanted by many
users. For sure also the possibility to "just" have the hydro part (or
whatever) of GRASS with a few clicks which would then also (ideally)
provide a GUI with only these modules in it.
I find that idea quite good.
- "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?
Maybe you can but it is neither sufficiently documented (see all the related
questions) nor sufficiently structured/complete to be a Python API to GRASS
or whatever you want to call it.
Markus
2011/3/27 Markus Neteler <neteler@osgeo.org>:
- "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?Maybe you can but it is neither sufficiently documented (see all the related
questions) nor sufficiently structured/complete to be a Python API to GRASS
or whatever you want to call it.
for inspiration try out Python API of ESRI ArcGIS 10...
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi,
I am willing to help with Raster OpenMP programming for SoC
- "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..
+> Maybe we can learn from the R experience in handling plugins...
+>Also a core GRASS GIS < 10Mb can be distributed and then download of
your "groups" of functionalities aka what Erdas/Imagine does or Matlab
or LibreOffice.
- "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?
+> R "raster" package and its now extensive group can maybe give us
ideas of the potential there.