GRASS-Wiki - User contributions [en]

GRASS GIS at OSGeo Community Sprint 2022

2022-08-27T09:55:47Z

⚠️Wolf: Renamed section

{{toc|right}}

[https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2022 ''OSGeo Community Sprint 2022''], Florence, Aug 27-28, 2022.

<center>
[[File:GRASS_GIS_Code_Sprint_2018.png|320px]]
</center>

== Introduction ==

Participation is free of charge and anyone involved or interested in getting involved in OSGeo community projects is welcome.

This year we will try to offer the format '''an hour with the developer''', where we ask seasoned community members to donate time for welcoming new members and introduce them to different projects or guide them through the setup of the development environment or translation tools and get started on the Foss4G journey.

You can choose to contribute to one or more projects. The sky is the limit. There’s always plenty to do – and it’s not all about programming. Translation, documentation, feedback, discussions, and testing are very important for projects! Conference registration is not a prerequisite for participation in the code sprint.

=== When ===

The code sprint will be held on 27-28 of August.

=== Where ===

The codesprint will be hosted at the University of Florence.

* onsite: Centro Didattico Morgagni UniFi in Viale Morgagni 42 -- 44 Firenze ([https://umap.openstreetmap.fr/it/map/foss4g-2022-sites_776000#16/43.7978/11.2472 map]).
* online: https://gitter.im/grassgis/sprint

== Goals ==

=== Command Line Improvements ===
* Finish issues [https://github.com/OSGeo/grass/issues/942 #942] [https://github.com/OSGeo/grass/issues/753 #753] [https://github.com/OSGeo/grass/issues/964 #964] - A unified colorful prompt across all shells
** I need help with windows for testing if color works as expected
** Get clarification on whether issue #970 is up for grabs
** Discuss with Vaclav about introducing sub commands into grass.py, and maybe get it started.

=== Discuss naming and presentation of GRASS GIS data hierarchy ===
* Kladivova, Petrasova, Petras, Landa (2022, not published): ''GRASS GIS was conceived from its very beginning as a powerful geospatial computing tool that emphasized data integrity to deliver accurate results. To achieve consistent results when working with data from different sources, GRASS GIS requires the data to be imported into GRASS data storage and reprojected into a common coordinate reference system (CRS) predetermined by the user for each project. Within each project, called location, data are further organized into subprojects, called mapsets, used for managing different subregions or analyses. Additionally, mapsets have distinct processing settings such as computational extent and resolution. The directory with one or more locations is referred to as GRASS database and is typically named grassdata.''
* location and mapset -> project and subproject
* GRASS database (GISDBASE, database directory) -> not needed as a prominent concept; a path, directory (folder) which happens to have one or more projects
* More than just a rename, but different presentation.
* g.project.switch (or g.switch.project) - change current project or subproject
* g.search.path - manage visibility of data in other subprojects
* g.mapset and g.mapsets kept for backwards compatibility
* grass.script.setup.init - add project and subproject keyword arguments; keep location and mapset
* Workspace file (.gxw) -> automatically created in each subproject with the last used GUI state, but still needs to be available as now for things like 3D animations and g.print.ws
* PERMANENT
** permanent versus temporary confusion
** alternative names: default, base, main (if common files are moved to location, there is no need for a specific name at all)
** also as a default subproject (mapset)? Path to project (location) would translate to project/{default}, e.g., project/PERMANENT

=== Tools versus Modules ===

* Modular: A component added to a modular system
* Tools: A things which does things

=== NC sample data on the website ===

* Rename https://grass.osgeo.org/download/data/#NorthCarolinaDataset: take out <tt>_grass7</tt> to not confuse G8 users

=== New semantic versioning and GitHub milestones ===

* rename label 8.4 to 8.3?

=== Marketing ===

* Best practice (recommendations) how to make a presentation on GRASS GIS
** existing good material (e.g., reveal.js slides)
** what should be mentioned
** adversise the mailing list and new communication platform
** ... add more.
* add link to Anna's presentation on parallelization --> and blogpost
* add link to Vashek's presentation on code style --> and blogpost

=== Parallel processing ===

* r.mapcalc.tiled/r.*.tiled: set default window to non-square for faster row-based computation
* develop a script which tests a combination of nprocs/memory settings to guide the user what to use on the particular machine
* add link to Anna's presentation on parallelization

=== Tests ===

* Document how to write test (or prominently say where this is already documented)

=== Sponsorship ===

* add different levels
* explain better what it is a good idea to donate money (what is the value gained for the donor)

=== GitHub maintenance ===

* use a project board (?) - discuss

=== Message Translation ===

* how to backport translations (weblate pull requests)

=== Student grants ===

* define content of new round

=== Web site ===

* Add roadmap, with iframe pointing to milestones in GitHub?

=== Juyper notebooks ===

* fix timeseries plot which runs into an endless loop in t.rast.series - SQLite locking mess

=== ===

=== ===

=== ===

=== ===

== Reports ==

=== Saturday ===

==== You ====

* ...

=== Sunday ===

==== You ====

* ...

=== See also ===

* https://wiki.osgeo.org/wiki/FOSS4G_2022/Community_sprint

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2022]]

GRASS GIS at OSGeo Community Sprint 2022

2022-08-26T18:34:17Z

⚠️Wolf: /* Goals */ Wolf's goals

GRASS SoC Ideas 2012

2012-02-19T21:42:03Z

⚠️Wolf:

<center>

[[Image:grasslogo_vector_small.png|link=http://grass.osgeo.org]]<font size="+3"> @ </font> [[Image:Gsoc-2012-logo-color.png|250px|link=http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012]] <font size="+3"> @ </font> [[Image:OSGeo 220pix.png|link=http://www.osgeo.org]]
</center>

* See also previous Google Summer of Code [[GRASS SoC Ideas 2011|ideas from 2011]].

* Visit the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 main OSGeo Google Summer of Code 2012 @ OSGeo wiki page].

----

__TOC__
== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2012]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

* [http://code.google.com/soc/ Official Google Summer of Code 2012 homepage]
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 OSGeo SoC 2012 homepage]

Promotion:
* OSGeo Flyer at <s>http://svn.osgeo.org/osgeo/marketing/flyer/google_summer_of_code/OSGeo_GSoC_2012.pdf </s>(todo)
* Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
* More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

* '''[http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#timeline The official timeline]'''

== Required Steps ==

* List ideas

* Assign Mentors to Ideas

* Notify OSGeo

* Mentors evaluate student applications

* Accepted students announced

* Students subscribe to the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev mailing list] and introduce themselves

* Mentor will create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://grass.osgeo.org/programming7/rfc2_psc.html RFC2] to the [http://lists.osgeo.org/mailman/listinfo/grass-psc 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 [[GRASS SoC Ideas 2007#Ideas|2007]], [[GRASS SoC Ideas 2008#Ideas|2008]], [[GRASS SoC Ideas 2009#Ideas|2009]], [[GRASS SoC Ideas 2010#Ideas|2010]], and [[GRASS SoC Ideas 2011#Ideas|2011]] which are still open'''.

* Project ideas of your own are also most welcome and often the best.

=== wxGUI ===

<ol>
<li> 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]].
<center>
[[Image:Wxgui_current.png|300px|thumb|left|Current wxGUI layout with detached window components]]
[[Image:Wxgui_proposal.png|300px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
</center>
<li> Add '''WMS and/or TiledMapService and/or WMS-T 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. [[WXGUI WMS service rendering GSoC 2011|GRASS WXGUI WMS service rendering project GSoC wiki page]]
<li> Develop a GUI module in wxPython for '''creating animations''' from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files. See existing modules {{cmd|xganim}}, {{cmd|r.out.mpeg}}, [[NVIZ]]'s animation tools, and the [[Movies]] creation wiki page. (co-mentor Helena Mitasova).

<li> ''Your idea here''

</ol>
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:MarisN|Maris Nartiss]], [[User:Mmetz|Markus Metz]], (''your name here'')

=== Raster ===

#Add '''[[OpenMP]] parallelization''' where appropriate, for example {{cmd|r.cost}}, {{cmd|r.surf.contour}}, {{cmd|r.watershed}}. It is important to understand which modules are processor bound, and concentrate on them. i.e. do not needlessly complicate the code of non-long running processor bound modules. A good working knowledge of ANSI C and {{wikipedia|OpenMP}} is required. ({{wikipedia|OpenCL}} and {{wikipedia|pthreads}} are fine too!)
#Create a new GRASS module to find the {{wikipedia|topographic_prominence}} of peaks from a raster elevation map within the region. (probably this would only make up 1/4 to 1/2 of a multi-part GSoC project)
# Expand maximum grid size for {{cmd|r.watershed}}. [[LIDAR]]-based elevation grids are at finer resolution than previous elevation models, often overwhelming the integer variable limit for grid size.
# ''Your suggestion here!''

'''Willing to Mentor:''' Hamish (co-mentor parallelization and prominence projects), Wolf Bergenheim(''your name here'')

=== Vector ===

# Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)''. (OpenCL and pthreads are fine too!) See above idea in the [[GRASS SoC Ideas 2011#Raster|Raster section]].
# Better '''support for wrap-around at 180 longitude''': Currently the raster engine is pretty good at wrapping data over 180 longitude. The vector data isn't, but it should be. This is a great task if by the end of the summer you'd like to be familiar with the implementation method of an entire vector stack of a fully featured modern GIS.
# Add '''break lines support to interpolation modules''' ({{cmd|v.surf.rst}}, {{cmd|v.surf.idw}}, {{cmd|v.surf.bspline}}). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See [http://www.spatialanalysisonline.com/output/html/Breaklinesandnaturalboundaries.html Geospatial Analysis - a comprehensive guide. 3rd edition] for description. [*] well, some support exists, see {{AddonCmd|v.surf.icw}}.
# Speed up wxGUI handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd).
# ''Your idea here'' ...

'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:Mmetz|Markus Metz]], Hamish (co-mentor for parallelization), Wolf Bergenheim, (''your name here'')

=== Imagery ===

# GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implemented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
#* We need someone willing to '''port the old modules to work with GRASS 7''', including writing new '''wxPython GUI frontends''' to a number of existing tools and updating the imagery libraries to current raster library standards.
#* In addition, there are a number of '''improved/automated georectification tools''' which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.
# Implement '''[[OpenMP]] (multithreading)''' as much as possible (where appropriate; OpenCL and pthreads are fine too)
# In addition to the porting of the georectification tools mentioned above, it would be interesting to implement an orthorectification tool for satellite imagery. Currently, GRASS only has i.ortho.photo for aerial photographs.
# Implement image segmentation algorithms and tools
# Implement region-based classification
# Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)
# ''Your idea here''

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|ideas for imagery improvement]] and [http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib GRASS 7 ideas] wiki pages for more details.

'''Willing to Mentor:''' Hamish (co-mentor for parallelization), (''your name here'')

=== 3D visualization ===

# Optimize OGSF (and NVIZ/wxNVIZ) to '''display large 3D point clouds with uninterupted tought speed'''. OGSF + (wx)NVIZ should be able to rotate point cloud (i.e. LiDAR dataset) with 4 millions of points on medium hardware (i.e. 2GHz CPU with 2Gb RAM and GPU with hardware transform and lighting support and dedicated video RAM) with response time not greater than 1.0 second.
# Design and implement '''text displaying and styling in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should be user configurable (fonts, colors, effects etc.) and multilanguage friendly.
# Design and implement user-provided '''symbol support in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should support GRASS symbols, SVG, and/or simple EPS symbols.

# Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency).
'''Willing to Mentor:''' [[User:Landa|Martin Landa]] (for 2), co-mentor for 1 and 4: Helena Mitasova, (''your name here'')

=== Volume modeling ===

# implement color management for 3D rasters : '''r3.colors'''
# develop '''r3.flow''' for computing 3D flow lines and 3D flow accumulation from 3D rasters
# enhance volume interpolation module '''{{cmd|v.vol.rst}}''' for handling of data in space-time cube, including computation of gradients and hypercurvatures

'''Willing to Mentor:''' co-mentor Helena Mitasova, (''your name here'')

=== Other ===

* See also the [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&type=enhancement GRASS wish list]

# Design and implement modern '''metadata management system''' for GRASS to support [http://www.opengeospatial.org/standards/cat OGC CSW] and INSPIRE discovery a view services

# Design '''sophisticated Python scripting interface''' for GRASS based on [http://grass.osgeo.org/programming7/pythonlib.html GRASS Python Scripting Library]
# ''Your idea here''

'''Willing to Mentor:''' Wolf Bergenheim (Python API, metadata management) (''your name here'')

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing our [http://lists.osgeo.org/mailman/listinfo/grass-dev dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* [http://lists.osgeo.org/mailman/listinfo/soc The OSGeo SoC mailing list]



* If you are thinking about applying, do make a point of reading the "[http://google-opensource.blogspot.co.nz/2011/02/flip-bits-not-burgers-student-guide.html Flip bits not Burgers: The Student's Guide to the Summer of Code]" eBook

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse

* Please review the submitting files for our coding standards
** {{src|SUBMITTING|branch=trunk}} for C coding rules
** {{src|SUBMITTING_PYTHON|branch=trunk}} for Python coding rules
** {{src|SUBMITTING_DOCS|branch=trunk}} for Documentantion coding rules

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Guidelines for Mentors ==

* Un(?)official book: http://www.booki.cc/gsoc-mentoring/
* Some more hints on the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012_Administrative#Links OSGeo wiki]

== Accepted Ideas ==

# ''Project name''
#: Student: Your name here
#: Mentor: Your mentor's name here
#: Backup mentor: Your backup mentor's name here
#: Wiki page: wiki page maintained by you (typically in this GRASS wiki, or the trac development wiki)
# ''Project name''
#: Student: Someone else's name here
#: Mentor: Their mentor's name here
#: Backup mentor: Their backup mentor's name here
#: Wiki page: wiki page maintained by them (typically in this GRASS wiki, or the trac development wiki)

[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS SoC Ideas 2009

2009-03-26T20:52:19Z

⚠️Wolf: /* Other */

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php 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 [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* While the GUI is becoming very powerful, there is potential for improvement of the layout. It is suggested to reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figure below). Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] and mind your users (and where they come from - think newcomers to the GRASS world - "Don't Limit Your User Base" by being too different from others). If possible, this could be implemented as ''skin'' to give users choices to also get wxGUI as Multiple Document Interface (MDI, i.e, the wxGUI windows reside under a single parent window). More [[WxGUI#Layout|here]].

[[Image:Wxgui_current.png|200px|thumb|center|Current wxGUI layout with detached window components]]
[[Image:Wxgui_proposal.png|200px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]

* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries ([http://trac.osgeo.org/osgeo4w/ OSGeo4W]?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

* Continue in [[wxNviz]] development.

* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

* Develop a [[WxPython-based_GUI_for_GRASS#Cartography_tools|graphical cartographic module]] - something like a GUI front-end or replacement for ps.map

* Create a fully functional command line interface with history within the GUI (see [http://trac.osgeo.org/grass/ticket/528#comment:6 suggestion])

* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

====Kriging GUI====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to create a GUI (in wxPython) that can:
# Do Kriging based on R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.

: See [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.autokrige v.autokridge] in Addons

'''Willing to Mentor:'''Wolf Bergenheim

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

* Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of [http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan GRASS 6.4 Feature Plan].

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

=== Other ===

* Continue the development of [[WinGRASS_Current_Status|GRASS for Windows]]. We are especially interested in having GRASS work on Windows Vista.

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS SoC Ideas 2009

2009-03-26T20:51:15Z

⚠️Wolf: /* Ideas */

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php 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 [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* While the GUI is becoming very powerful, there is potential for improvement of the layout. It is suggested to reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figure below). Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] and mind your users (and where they come from - think newcomers to the GRASS world - "Don't Limit Your User Base" by being too different from others). If possible, this could be implemented as ''skin'' to give users choices to also get wxGUI as Multiple Document Interface (MDI, i.e, the wxGUI windows reside under a single parent window). More [[WxGUI#Layout|here]].

[[Image:Wxgui_current.png|200px|thumb|center|Current wxGUI layout with detached window components]]
[[Image:Wxgui_proposal.png|200px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]

* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries ([http://trac.osgeo.org/osgeo4w/ OSGeo4W]?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

* Continue in [[wxNviz]] development.

* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

* Develop a [[WxPython-based_GUI_for_GRASS#Cartography_tools|graphical cartographic module]] - something like a GUI front-end or replacement for ps.map

* Create a fully functional command line interface with history within the GUI (see [http://trac.osgeo.org/grass/ticket/528#comment:6 suggestion])

* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

====Kriging GUI====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to create a GUI (in wxPython) that can:
# Do Kriging based on R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.

: See [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.autokrige v.autokridge] in Addons

'''Willing to Mentor:'''Wolf Bergenheim

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

* Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of [http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan GRASS 6.4 Feature Plan].

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

=== Other ===

* Continue the development of [[WinGRASS_Current_Status|GRASS for Windows]].

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS SoC Ideas 2009

2009-03-23T10:54:30Z

⚠️Wolf: /* wxGUI */ Added The Kriging idea from 2008

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php 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 [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* While the GUI is becoming very powerful, there is potential for improvement of the layout. It is suggested to reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figure below). Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] and mind your users (and where they come from - think newcomers to the GRASS world - "Don't Limit Your User Base" by being too different from others). If possible, this could be implemented as ''skin'' to give users choices to also get wxGUI as Multiple Document Interface (MDI, i.e, the wxGUI windows reside under a single parent window). More [[WxGUI#Layout|here]].

[[Image:Wxgui_current.png|200px|thumb|center|Current wxGUI layout with detached window components]]
[[Image:Wxgui_proposal.png|200px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]

* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries ([http://trac.osgeo.org/osgeo4w/ OSGeo4W]?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

* Continue in [[wxNviz]] development.

* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

* Develop a [[WxPython-based_GUI_for_GRASS#Cartography_tools|graphical cartographic module]] - something like a GUI front-end or replacement for ps.map

* Create a fully functional command line interface with history within the GUI (see [http://trac.osgeo.org/grass/ticket/528#comment:6 suggestion])

* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.

: See v.autokridge in Addons

'''Willing to Mentor:'''Wolf Bergenheim

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

* Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of [http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan GRASS 6.4 Feature Plan].

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS 7 Terminology

2008-05-01T18:03:34Z

⚠️Wolf: /* Layer contra Map */

This page is dedicated to discussion about changes in terminology for GRASS 7.

== Layer contra Map ==

'''Background''':
Currently data entities like raster or vector are called in GRASS "maps", i.e. "raster map" or "vector map".

* [[User:Landa|ML]]: GRASS is basically '''"layer-based"''' GIS, calling single raster or vector entities as "maps" is quite confusing. Better would be to use term "layer" for this purpose. "Map" can be used for layer composition, e.g. for cartography outputs.

'''Background''':
The term "vector layer" is currently used even in more confusing sense, to mark subgroup of vector objects in vector entity. Originally called as "field".

* [[User:Landa|ML]]: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".
* WB: How about calling it "attribute-layer" which connects to an "attribute-table" (DB table)?

== See also ==

* [http://grass.osgeo.org/gdp/html_grass5/terminology.html GRASS 5 terminology]
* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].

[[Category: Development]]

GRASS 7 Terminology

2008-05-01T18:02:13Z

⚠️Wolf: /* Layer contra Map */ Added some thoughts on terminology

This page is dedicated to discussion about changes in terminology for GRASS 7.

== Layer contra Map ==

'''Background''':
Currently data entities like raster or vector are called in GRASS "maps", i.e. "raster map" or "vector map".

* [[User:Landa|ML]]: GRASS is basically '''"layer-based"''' GIS, calling single raster or vector entities as "maps" is quite confusing. Better would be to use term "layer" for this purpose. "Map" can be used for layer composition, e.g. for cartography outputs.

'''Background''':
The term "vector layer" is currently used even in more confusing sense, to mark subgroup of vector objects in vector entity. Originally called as "field".

* [[User:Landa|ML]]: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".
* WB: How about calling it "attribute-layer" or better yet: "attribute-table"?

== See also ==

* [http://grass.osgeo.org/gdp/html_grass5/terminology.html GRASS 5 terminology]
* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].

[[Category: Development]]

GRASS 7 ideas collection

2008-04-27T15:48:40Z

⚠️Wolf: /* fix */ Added link v.generalize to manual page

{{MoveToTrac}}
== Maintenance of repository ==

For grass7 development will be used svn-trunk, for grass6 must be created new branch.

Planning is continued here: http://trac.osgeo.org/grass/wiki/Grass7Planning

== Raster ==

See also [[Replacement raster format]]

=== Library ===
* allowing nulls to be embedded
* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export
* rename r.volume 'data' parameter to something more standard like 'input' or 'map'

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 integer/floating point detection for AAIGrid driver in GDAL] was fixed after 1.3.2 release, so r.in.gdal and r.out.gdal should be enough now.

* remove '''r.resample''' and '''r.bilinear''' in favor of '''r.resamp.interp'''
* remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 RT #3680] (starting with date Sun, Nov 26 2006 14:54:23).
: It might be worth keeping r.out.tiff! It makes a nice delta when things don't go well (eg [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB

* Remove remaining -v and -q flags for verbosity levels of modules.

==== Merge ====

* merge '''r.surf.idw''' and '''r.surf.idw2'''
: while r.surf.idw will only output CELL maps, it is Very Fast.

* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* r.resamp.rst: merge into r.resamp.interp to make resolution management identical to the other modules

* r.in.wms and r.in.srtm into r.in.gdal thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
* '''r.buffer''' and '''r.grow'''

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html list of affected modules]
* fix the raster map history management (truncating long history, odd storage). It should work like for vector maps in GRASS 6.
* r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg Geologic Cross Sections])
* implement transactions for geometry handling (esp. v.edit, v.digit and to avoid leftover files when a vector command fails)
* Assume '''cat 0''' as the first possible, instead of 1. GRASS has supported cat 0 since around 2005, but it hasn't been widely used. According to Radim, using cat 0 allows for [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com exact mapping from OGR FID (which can be 0) to GRASS cat].
* support for elliptical arcs, quadratic and cubic splines. Elliptical arcs or circular arcs are very common in Swiss survey data (Amtliche Vermessung)

=== Modules ===

==== rename ====
* rename v.in.ogr to v.import
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge v.sample and v.what.rast
: See a feature request [http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506] in GForge.

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 Column 'cat_' already exists (duplicate name)] in v.in.ogr. Maybe by creating columns ''cat_1'', ''cat_2'' etc. each time a Grass vector is exported to shapefile and imported back to Grass?
* write Vect_map_exists() and implement in g.remove and v.digit -n (why wait for GRASS 7 ??)
* add '-d' dissolve to v.reclass
* add 'where=' to v.to.rast (why wait for GRASS 7 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html v.generalize] does D-P and a lot more -WB
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlapping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
* v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
* v.type - change type= option to from= and to=.(code's already in there)

==== enhance ====
* extend v.overlay to allow combination of all types (point, line, area)
* v.category: add possibility to create new layer categories on the basis of a column in the table linked to an existing layer

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be).

== Database ==
=== Library ===

* establish SQLite as default DBMI driver (DBF is too limited)

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names

== Imagery ==
=== Library ===

Do merge of image libraries:

* A)
** lib/imagery/: standard lib, in use (i.* except for i.points3, i.rectify3)
** imagery/i.ortho.photo/libes/: standard lib, in use (i.ortho.photo, photo.*)
* B)
** lib/image3/: never finished improvement which integrated the standard lib and the ortho lib. Seems to provide also ortho rectification for satellite data (i.points3, i.rectify3)

=== Modules ===

* merge of i.points, i.vpoints, i.points3
: drop these altogether? (loss of interactive XDRIVER)
* merge of i.rectify and i.rectify3
: maybe depend on gdalwarp C API for this?
* addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
* add other warping methods (maybe thin splines from GDAL?)
* implement/finish linewise ortho-rectification of satellite data
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

== Raster3D ==
=== Library ===
* renaming of all G3D library functions to fulfil the grass coding standard
* extent/rewrite documentation
* localisation support (why wait for GRASS 7 ??)

=== Modules ===
* report and support modules like r3.stats, r3.support
* voxel -> vector (isosurfaces ...) and vector -> voxel (lines, faces, volumes) conversion modules
* module for 3d Kriging interpolation based on vector points
* a GRASS-Python/VTK visualisation/manipulation tool

== Display ==

=== New display architecture ===

''Comments from Glynn Clements (from [http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13206009 here]):''

# Eliminating separate driver processes. Having to extend the protocol for each new operation has been a major drag on development.
# Use of floating-point for all graphics coordinates. For geographic data, the expected approach will be to set an appropriate transform then use cartographic coordinates.
# Common architecture for both video and hardcopy output. ps.map should be redundant.

In retrospect, #1 means that we don't really need support for the Windows/MacOSX GUI, just the ability to generate image files.

With X, we could take the shortcut of having d.* commands draw directly into an existing window, but I don't know whether that's possible on other platforms.

OTOH, it might be useful to be able to use the same functions for self-contained GUI programs (e.g. vector digitising) as for d.* commands.

=== Library ===
* Drop support for interactive xmon modules

=== Modules ===
* d.font etc.
** Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
** merge d.font and d.font.freetype too
: now done in 6.3?

* d.vect
** consolidate parameter names (attrcol, wcolumn, rgb_column)
: how?

* remove d.ask, d.menu, d.linegraph(?), d.mapgraph, d.text.freetype, d.paint.labels (symlink), d.font.*

* remove d.m

* d.legend, d.barscale, d.text, etc: make at=0,0 origin identical!
: FWIW, I copied the d.legend at= syntax from d.frame --HB

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)

See also "New display architecture" comments above.

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [http://intevation.de/rt/webrt?serial_num=2969 '''v.type''' doesn't allow for selecting input and output type in '''GUI''']

* Making GRASS modules be less verbose. Use --verbose flag and GRASS_VERBOSE environment variable. All output (G_message, G_percetn, G_warning) should go to GRASS_LOG file which could be grassdata/location/mapset/.grass.log by default.
: less verbose: this is well underway in 6.3
: Note warning and errors are already logged to GIS_ERROR_LOG (see variables.html)

== Init shell and startup ==

* .grassrc6 is not what you expect. It holds the g.gisenv GIS variables, it's not a shell script containing commands like .bashrc is.
: Suggestion: We should change the name for 7.x. It isn't an "rc" file in the conventional sense.
:: Suggestion: make it even a $HOME/.grass7/ directory to store settings etc (e.g., from r.li and others)

* It is asked to run GRASS in its own shell to avoid portability issues [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y GRASS user ML]: "Most of the environment can be set up through an e.g. /etc/env.d/grass script. The database, location and mapset can be set through g.mapset. The only slight subtlety is if you want multiple independent sessions, but that can be done with a fraction of the code in Init.sh."

* Provide a mechanism (g.access option?) to enable r/w access for users in mapsets they don't own. So that it they don't need to hack lib/gis/mapset_msc.c. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y GRASS user ML]: "AFAICT, that restriction has been unnecessary ever since the lockfile was moved from the user's home directory to the mapset directory."

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ units] software
: Support for free form unit meta-data added in 6.3. I don't mind it as a guide, but we shouldn't be limited to units found in ''units''. --HB

* store vertical map datum on per-location base (GDAL/OGR needs the same [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html enhancement])
: This requires more discussion. I'm not sure it's a good idea to do this location-wide. --HB
: On a per raster map basis done in 6.3 cvs.

* add versioning for maps (to recover previous map versions)
: see "v.info -h" ?

== Time series ==

* Implement better [[Time series in GRASS]] support (series of satellite data etc)
: for example?

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* please, remove before GRASS 7 released */
if(q->answer) {
putenv("GRASS_VERBOSE=0");
G_warning(_("The '-q' flag is superseded and will be removed "
"in future. Please use '--quiet' instead"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS

* → [[WxPython-based GUI for GRASS]]

== Conceptual changes ==

* File organization in binaries:
** the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- <cite> frankie at #grass irc</cite>
** it's basically a FHS violation, i dunno if it is reported by lintian, anyway /usr/lib/grass should be used for arch-deps data, not for mixed stuff -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
**(Add support for Paraview in GDAL/OGR or add GDAL/OGR support in ParaView to read directly data from GRASS) see discussion
* Or use [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2008-04-27T15:47:15Z

⚠️Wolf: /* fix */ Added more information on D-P

{{MoveToTrac}}
== Maintenance of repository ==

For grass7 development will be used svn-trunk, for grass6 must be created new branch.

Planning is continued here: http://trac.osgeo.org/grass/wiki/Grass7Planning

== Raster ==

See also [[Replacement raster format]]

=== Library ===
* allowing nulls to be embedded
* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export
* rename r.volume 'data' parameter to something more standard like 'input' or 'map'

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 integer/floating point detection for AAIGrid driver in GDAL] was fixed after 1.3.2 release, so r.in.gdal and r.out.gdal should be enough now.

* remove '''r.resample''' and '''r.bilinear''' in favor of '''r.resamp.interp'''
* remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 RT #3680] (starting with date Sun, Nov 26 2006 14:54:23).
: It might be worth keeping r.out.tiff! It makes a nice delta when things don't go well (eg [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB

* Remove remaining -v and -q flags for verbosity levels of modules.

==== Merge ====

* merge '''r.surf.idw''' and '''r.surf.idw2'''
: while r.surf.idw will only output CELL maps, it is Very Fast.

* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* r.resamp.rst: merge into r.resamp.interp to make resolution management identical to the other modules

* r.in.wms and r.in.srtm into r.in.gdal thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
* '''r.buffer''' and '''r.grow'''

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html list of affected modules]
* fix the raster map history management (truncating long history, odd storage). It should work like for vector maps in GRASS 6.
* r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg Geologic Cross Sections])
* implement transactions for geometry handling (esp. v.edit, v.digit and to avoid leftover files when a vector command fails)
* Assume '''cat 0''' as the first possible, instead of 1. GRASS has supported cat 0 since around 2005, but it hasn't been widely used. According to Radim, using cat 0 allows for [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com exact mapping from OGR FID (which can be 0) to GRASS cat].
* support for elliptical arcs, quadratic and cubic splines. Elliptical arcs or circular arcs are very common in Swiss survey data (Amtliche Vermessung)

=== Modules ===

==== rename ====
* rename v.in.ogr to v.import
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge v.sample and v.what.rast
: See a feature request [http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506] in GForge.

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 Column 'cat_' already exists (duplicate name)] in v.in.ogr. Maybe by creating columns ''cat_1'', ''cat_2'' etc. each time a Grass vector is exported to shapefile and imported back to Grass?
* write Vect_map_exists() and implement in g.remove and v.digit -n (why wait for GRASS 7 ??)
* add '-d' dissolve to v.reclass
* add 'where=' to v.to.rast (why wait for GRASS 7 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. v.generalize does D-P and a lot more -WB
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlapping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
* v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
* v.type - change type= option to from= and to=.(code's already in there)

==== enhance ====
* extend v.overlay to allow combination of all types (point, line, area)
* v.category: add possibility to create new layer categories on the basis of a column in the table linked to an existing layer

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be).

== Database ==
=== Library ===

* establish SQLite as default DBMI driver (DBF is too limited)

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names

== Imagery ==
=== Library ===

Do merge of image libraries:

* A)
** lib/imagery/: standard lib, in use (i.* except for i.points3, i.rectify3)
** imagery/i.ortho.photo/libes/: standard lib, in use (i.ortho.photo, photo.*)
* B)
** lib/image3/: never finished improvement which integrated the standard lib and the ortho lib. Seems to provide also ortho rectification for satellite data (i.points3, i.rectify3)

=== Modules ===

* merge of i.points, i.vpoints, i.points3
: drop these altogether? (loss of interactive XDRIVER)
* merge of i.rectify and i.rectify3
: maybe depend on gdalwarp C API for this?
* addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
* add other warping methods (maybe thin splines from GDAL?)
* implement/finish linewise ortho-rectification of satellite data
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

== Raster3D ==
=== Library ===
* renaming of all G3D library functions to fulfil the grass coding standard
* extent/rewrite documentation
* localisation support (why wait for GRASS 7 ??)

=== Modules ===
* report and support modules like r3.stats, r3.support
* voxel -> vector (isosurfaces ...) and vector -> voxel (lines, faces, volumes) conversion modules
* module for 3d Kriging interpolation based on vector points
* a GRASS-Python/VTK visualisation/manipulation tool

== Display ==

=== New display architecture ===

''Comments from Glynn Clements (from [http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13206009 here]):''

# Eliminating separate driver processes. Having to extend the protocol for each new operation has been a major drag on development.
# Use of floating-point for all graphics coordinates. For geographic data, the expected approach will be to set an appropriate transform then use cartographic coordinates.
# Common architecture for both video and hardcopy output. ps.map should be redundant.

In retrospect, #1 means that we don't really need support for the Windows/MacOSX GUI, just the ability to generate image files.

With X, we could take the shortcut of having d.* commands draw directly into an existing window, but I don't know whether that's possible on other platforms.

OTOH, it might be useful to be able to use the same functions for self-contained GUI programs (e.g. vector digitising) as for d.* commands.

=== Library ===
* Drop support for interactive xmon modules

=== Modules ===
* d.font etc.
** Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
** merge d.font and d.font.freetype too
: now done in 6.3?

* d.vect
** consolidate parameter names (attrcol, wcolumn, rgb_column)
: how?

* remove d.ask, d.menu, d.linegraph(?), d.mapgraph, d.text.freetype, d.paint.labels (symlink), d.font.*

* remove d.m

* d.legend, d.barscale, d.text, etc: make at=0,0 origin identical!
: FWIW, I copied the d.legend at= syntax from d.frame --HB

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)

See also "New display architecture" comments above.

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [http://intevation.de/rt/webrt?serial_num=2969 '''v.type''' doesn't allow for selecting input and output type in '''GUI''']

* Making GRASS modules be less verbose. Use --verbose flag and GRASS_VERBOSE environment variable. All output (G_message, G_percetn, G_warning) should go to GRASS_LOG file which could be grassdata/location/mapset/.grass.log by default.
: less verbose: this is well underway in 6.3
: Note warning and errors are already logged to GIS_ERROR_LOG (see variables.html)

== Init shell and startup ==

* .grassrc6 is not what you expect. It holds the g.gisenv GIS variables, it's not a shell script containing commands like .bashrc is.
: Suggestion: We should change the name for 7.x. It isn't an "rc" file in the conventional sense.
:: Suggestion: make it even a $HOME/.grass7/ directory to store settings etc (e.g., from r.li and others)

* It is asked to run GRASS in its own shell to avoid portability issues [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y GRASS user ML]: "Most of the environment can be set up through an e.g. /etc/env.d/grass script. The database, location and mapset can be set through g.mapset. The only slight subtlety is if you want multiple independent sessions, but that can be done with a fraction of the code in Init.sh."

* Provide a mechanism (g.access option?) to enable r/w access for users in mapsets they don't own. So that it they don't need to hack lib/gis/mapset_msc.c. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y GRASS user ML]: "AFAICT, that restriction has been unnecessary ever since the lockfile was moved from the user's home directory to the mapset directory."

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ units] software
: Support for free form unit meta-data added in 6.3. I don't mind it as a guide, but we shouldn't be limited to units found in ''units''. --HB

* store vertical map datum on per-location base (GDAL/OGR needs the same [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html enhancement])
: This requires more discussion. I'm not sure it's a good idea to do this location-wide. --HB
: On a per raster map basis done in 6.3 cvs.

* add versioning for maps (to recover previous map versions)
: see "v.info -h" ?

== Time series ==

* Implement better [[Time series in GRASS]] support (series of satellite data etc)
: for example?

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* please, remove before GRASS 7 released */
if(q->answer) {
putenv("GRASS_VERBOSE=0");
G_warning(_("The '-q' flag is superseded and will be removed "
"in future. Please use '--quiet' instead"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS

* → [[WxPython-based GUI for GRASS]]

== Conceptual changes ==

* File organization in binaries:
** the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- <cite> frankie at #grass irc</cite>
** it's basically a FHS violation, i dunno if it is reported by lintian, anyway /usr/lib/grass should be used for arch-deps data, not for mixed stuff -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
**(Add support for Paraview in GDAL/OGR or add GDAL/OGR support in ParaView to read directly data from GRASS) see discussion
* Or use [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS SoC Ideas 2008

2008-03-31T20:42:25Z

⚠️Wolf: /* Timeline */ updated to reflect Google's changes

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

= Timeline =

([http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline GSoC timeline])

* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Deadline for student's applications: April 7th
* Work Begins (May 26th)
* Midterm evaluation (July 7th-14th)
* Pencils down! (August 11-18th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas http://wolf.bergenheim.net/tmp/check.png
* Notify OSGeo http://wolf.bergenheim.net/tmp/check.png
* Process Student Applications. Deadline April 10th
* April 14th: Accepted Students Announced
* SVN branches and access for students
** 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 =

Here are some ideas you can base your application on
===wxPython===

These project ideas have to do with the [[WxPython-based GUI for GRASS]] of GRASS.

====3D Visualization====
3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Paul Kelly

* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
<strike># For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.</strike> cf: http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Moritz Lennert

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

:Note there is already [[WxPython-based GUI for GRASS#Attribute table manager|Attribute Table Manager]] in [[wxPython-based GUI for GRASS|wxPython GUI]], anyway [http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_modules/sqlbuilder.py SQL Builder] need complete reconstruction. -- ML (2008/03)

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools have a strong back end but lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates PostScript maps. This would be a first step towards a [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|graphical cartography tool]] for GRASS.

'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external: Virtual raster map linking ====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side the user still has to always import raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

====Time series management in GRASS====

A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc. A SQL based raster/vector map management is desired. A prototype is available [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d here].

See details at [[Time series in GRASS]]

====Improved Line of Sight Analysis====

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

'''Willing to Mentor:''' Paul Kelly

==== Raster Database ====

In GRASS vector maps can be connected to a database table as an attribute table. GRASS's CELL (integer) maps include label support via the v.category module. Currently this is rather basic, labels may have a dynamic component but they are still just labels (see the r.category help page; e.g. using the Spearfish sample dataset: "r.report landcover.30m", "r.category geology", ). The idea is to seamlessly link the CELL value with a integer "cat" column in a database table. That cat ID in the database would be linked to any number of other attributes. Once the DB connection is made, a method of raster cell selection by SQL query would be needed. See the db.* and v.db.* modules for GRASS's existing database management code.


Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim, Hamish Bowman

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification). See GRASS's existing i.* imagery modules for current clustering and classification modules.

'''Willing to Mentor:''' Moritz Lennert (as second mentor for the contents, not the programming)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented or deeply debugged with at least a partial rewrite.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== v.voronoi / v.delauny ====
These modules need to be reimplemented or deeply debugged as they are  sub-optimal. There are many good algorithms that can be used.

'''Willing to mentor:''' Wolf Bergenheim

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines; i.e. merge in v.select)

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS.

(would happen in the GRASS 7 development branch)

'''Willing to Mentor:''' Wolf Bergenheim

==== Auto-tuning for spline surface interpolation ====

GRASS's regularized spline with tension (RST) modules* do a very nice job of generating raster surfaces from point data (often massive point datasets) using a thin plate spline method. Good results currently require a lot of trial and error to fine-tune the modules' tension and smoothing parameters to match the input data and deal with segmentation jumps when the input data points are not evenly distributed in space. Your job would be to implement auto-tuning algorithms into the RST modules to short circuit the manual trial and error process, possibly taking advantage of the existing cross-validation support.

[*] v.surf.rst (2.5D), v.vol.rst (3D), r.resample.rst

=== Manual related ===

* Develop a searchable keyword navigator to easier find commands. Each command provides at least one keyword (should be more), a tree based navigator with free text entry could guide users through the available commands. Also a [http://en.wikipedia.org/wiki/HyperbolicTree HyperbolicTree] style tag cloud would be cool.

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailinglist], or come and talk to us in IRC (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-23T15:49:12Z

⚠️Wolf: /* Guidelines for Students */

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Work Begins (May 28th)
* Midterm evaluation (July 14th)
* Pencils down! (August 11th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas http://wolf.bergenheim.net/tmp/check.png
* Notify OSGeo http://wolf.bergenheim.net/tmp/check.png
* Process Student Applications. Deadline April 10th
* April 14th: Accepted Students Announced
* SVN branches and access for students
** 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 =

Here are some ideas you can base your application on
===wxPython===

These project ideas have to do with the [[WxPython-based GUI for GRASS]] of GRASS.

====3D Visualization====
3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Paul Kelly

* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
<strike># For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.</strike> cf: http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Moritz Lennert

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools have a strong back end but lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates PostScript maps. This would be a first step towards a [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|graphical cartography tool]] for GRASS.

'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external: Virtual raster map linking ====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side the user still has to always import raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

====Time series management in GRASS====

A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc. A SQL based raster/vector map management is desired. A prototype is available [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d here].

See details at [[Time series in GRASS]]

====Improved Line of Sight Analysis====

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

'''Willing to Mentor:''' Paul Kelly

==== Raster Database ====

In GRASS vector maps can be connected to a database table as an attribute table. GRASS's CELL (integer) maps include label support via the v.category module. Currently this is rather basic, labels may have a dynamic component but they are still just labels (see the r.category help page; e.g. using the Spearfish sample dataset: "r.report landcover.30m", "r.category geology", ). The idea is to seamlessly link the CELL value with a integer "cat" column in a database table. That cat ID in the database would be linked to any number of other attributes. Once the DB connection is made, a method of raster cell selection by SQL query would be needed. See the db.* and v.db.* modules for GRASS's existing database management code.


Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim, Hamish Bowman

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification). See GRASS's existing i.* imagery modules for current clustering and classification modules.

'''Willing to Mentor:''' Moritz Lennert (as second mentor for the contents, not the programming)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented or deeply debugged with at least a partial rewrite.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== v.voronoi / v.delauny ====
These modules need to be reimplemented or deeply debugged as they are  sub-optimal. There are many good algorithms that can be used.

'''Willing to mentor:''' Wolf Bergenheim

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines; i.e. merge in v.select)

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS.

(would happen in the GRASS 7 development branch)

'''Willing to Mentor:''' Wolf Bergenheim

==== Auto-tuning for spline surface interpolation ====

GRASS's regularized spline with tension (RST) modules* do a very nice job of generating raster surfaces from point data (often massive point datasets) using a thin plate spline method. Good results currently require a lot of trial and error to fine-tune the modules' tension and smoothing parameters to match the input data and deal with segmentation jumps when the input data points are not evenly distributed in space. Your job would be to implement auto-tuning algorithms into the RST modules to short circuit the manual trial and error process, possibly taking advantage of the existing cross-validation support.

[*] v.surf.rst (2.5D), v.vol.rst (3D), r.resample.rst

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailinglist], or come and talk to us in IRC (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-23T15:43:06Z

⚠️Wolf: /* v.voronoi / v.delauny */

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Work Begins (May 28th)
* Midterm evaluation (July 14th)
* Pencils down! (August 11th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas http://wolf.bergenheim.net/tmp/check.png
* Notify OSGeo http://wolf.bergenheim.net/tmp/check.png
* Process Student Applications. Deadline April 10th
* April 14th: Accepted Students Announced
* SVN branches and access for students
** 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 =

Here are some ideas you can base your application on
===wxPython===

These project ideas have to do with the [[WxPython-based GUI for GRASS]] of GRASS.

====3D Visualization====
3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Paul Kelly

* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
<strike># For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.</strike> cf: http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Moritz Lennert

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools have a strong back end but lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates PostScript maps. This would be a first step towards a [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|graphical cartography tool]] for GRASS.

'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external: Virtual raster map linking ====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side the user still has to always import raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

====Time series management in GRASS====

A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc. A SQL based raster/vector map management is desired. A prototype is available [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d here].

See details at [[Time series in GRASS]]

====Improved Line of Sight Analysis====

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

'''Willing to Mentor:''' Paul Kelly

==== Raster Database ====

In GRASS vector maps can be connected to a database table as an attribute table. GRASS's CELL (integer) maps include label support via the v.category module. Currently this is rather basic, labels may have a dynamic component but they are still just labels (see the r.category help page; e.g. using the Spearfish sample dataset: "r.report landcover.30m", "r.category geology", ). The idea is to seamlessly link the CELL value with a integer "cat" column in a database table. That cat ID in the database would be linked to any number of other attributes. Once the DB connection is made, a method of raster cell selection by SQL query would be needed. See the db.* and v.db.* modules for GRASS's existing database management code.


Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim, Hamish Bowman

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification). See GRASS's existing i.* imagery modules for current clustering and classification modules.

'''Willing to Mentor:''' Moritz Lennert (as second mentor for the contents, not the programming)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented or deeply debugged with at least a partial rewrite.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== v.voronoi / v.delauny ====
These modules need to be reimplemented or deeply debugged as they are  sub-optimal. There are many good algorithms that can be used.

'''Willing to mentor:''' Wolf Bergenheim

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines; i.e. merge in v.select)

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS.

(would happen in the GRASS 7 development branch)

'''Willing to Mentor:''' Wolf Bergenheim

==== Auto-tuning for spline surface interpolation ====

GRASS's regularized spline with tension (RST) modules* do a very nice job of generating raster surfaces from point data (often massive point datasets) using a thin plate spline method. Good results currently require a lot of trial and error to fine-tune the modules' tension and smoothing parameters to match the input data and deal with segmentation jumps when the input data points are not evenly distributed in space. Your job would be to implement auto-tuning algorithms into the RST modules to short circuit the manual trial and error process, possibly taking advantage of the existing cross-validation support.

[*] v.surf.rst (2.5D), v.vol.rst (3D), r.resample.rst

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-23T15:36:40Z

⚠️Wolf: /* Required Steps */

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Work Begins (May 28th)
* Midterm evaluation (July 14th)
* Pencils down! (August 11th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas http://wolf.bergenheim.net/tmp/check.png
* Notify OSGeo http://wolf.bergenheim.net/tmp/check.png
* Process Student Applications. Deadline April 10th
* April 14th: Accepted Students Announced
* SVN branches and access for students
** 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 =

Here are some ideas you can base your application on
===wxPython===

These project ideas have to do with the [[WxPython-based GUI for GRASS]] of GRASS.

====3D Visualization====
3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Paul Kelly

* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
<strike># For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.</strike> cf: http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton, Moritz Lennert

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools have a strong back end but lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates PostScript maps. This would be a first step towards a [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|graphical cartography tool]] for GRASS.

'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external: Virtual raster map linking ====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side the user still has to always import raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

====Time series management in GRASS====

A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc. A SQL based raster/vector map management is desired. A prototype is available [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d here].

See details at [[Time series in GRASS]]

====Improved Line of Sight Analysis====

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

'''Willing to Mentor:''' Paul Kelly

==== Raster Database ====

In GRASS vector maps can be connected to a database table as an attribute table. GRASS's CELL (integer) maps include label support via the v.category module. Currently this is rather basic, labels may have a dynamic component but they are still just labels (see the r.category help page; e.g. using the Spearfish sample dataset: "r.report landcover.30m", "r.category geology", ). The idea is to seamlessly link the CELL value with a integer "cat" column in a database table. That cat ID in the database would be linked to any number of other attributes. Once the DB connection is made, a method of raster cell selection by SQL query would be needed. See the db.* and v.db.* modules for GRASS's existing database management code.


Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim, Hamish Bowman

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification). See GRASS's existing i.* imagery modules for current clustering and classification modules.

'''Willing to Mentor:''' Moritz Lennert (as second mentor for the contents, not the programming)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented or deeply debugged with at least a partial rewrite.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== v.voronoi / v.delauny ====
These modules need to be reimplemented or deeply debugged as they are  sub-optimal. There are many good algorithms that can be used.

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines; i.e. merge in v.select)

'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS.

(would happen in the GRASS 7 development branch)

'''Willing to Mentor:''' Wolf Bergenheim

==== Auto-tuning for spline surface interpolation ====

GRASS's regularized spline with tension (RST) modules* do a very nice job of generating raster surfaces from point data (often massive point datasets) using a thin plate spline method. Good results currently require a lot of trial and error to fine-tune the modules' tension and smoothing parameters to match the input data and deal with segmentation jumps when the input data points are not evenly distributed in space. Your job would be to implement auto-tuning algorithms into the RST modules to short circuit the manual trial and error process, possibly taking advantage of the existing cross-validation support.

[*] v.surf.rst (2.5D), v.vol.rst (3D), r.resample.rst

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-12T19:37:50Z

⚠️Wolf: Fiddling with the general layout

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
* Work Begins (May 28th)
* Midterm evaluation (July 14th)
* Pencils down! (August 11th)

= Required Steps =

* List ideas http://wolf.bergenheim.net/tmp/check.png
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* April 14th: Accepted Students Announced
* SVN branches and access for students
** 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 =

Here are some ideas you can base your application on
===wxPython===
These project ideas have to do with the new GUI of GRASS

====3D Visualization====
GRASS has an old Tcl based n-dimensional visualization tool. However since we are moving over to the new wxPython-based GUI we will need something similar for the new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
# For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates postscript maps. This would be a first step towards a graphical cartography tool for GRASS

'''Willing to Mentor:''' Michael Barton, Hamish Bowman

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side on is unfortunately limited to importing raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

==== Raster Database ====
In GRASS vector maps can be connected to a database table as an attribute table. Many commercial GIS packages also allow this for raster maps.

Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
'''Willing to Mentor:''' Wolf Bergenheim

==== v.voronoi / v.delauny ====
These modules need to be reimplemented as they are quite old an sub-optimal. There are many good algorithms that can be used.

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

'''Willing to Mentor:''' Wolf Bergenheim

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS

'''Willing to Mentor:''' Wolf Bergenheim

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-12T19:18:23Z

⚠️Wolf: /* Ideas */ intorduction

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

* For inspiration see the [[GRASS SoC Ideas 2007]] page

= Timeline =
* Community bonding time (getting to know the students)
* Work Begins
* Midterm evaluation
* Pencils down!

= Required Steps =

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* YYY: Accepted Students Announced
* SVN branches and access for students
* Coding begins...
* Students and mentors: Complete the Mid-term survey.
* Final commit and packaging for Google.

= Ideas =

Here are some ideas you can base your application on
===wxPython===
These project ideas have to do with the new GUI of GRASS

====3D Visualization====
GRASS has an old Tcl based n-dimensional visualization tool. However since we are moving over to the new wxPython-based GUI we will need something similar for the new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
# For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates postscript maps. This would be a first step towards a graphical cartography tool for GRASS

'''Willing to Mentor:''' Michael Barton, Hamish Bowman

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side on is unfortunately limited to importing raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

==== Raster Database ====
In GRASS vector maps can be connected to a database table as an attribute table. Many commercial GIS packages also allow this for raster maps.

Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
'''Willing to Mentor:''' Wolf Bergenheim

==== v.voronoi / v.delauny ====
These modules need to be reimplemented as they are quite old an sub-optimal. There are many good algorithms that can be used.

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

'''Willing to Mentor:''' Wolf Bergenheim

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS

'''Willing to Mentor:''' Wolf Bergenheim

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Suggested Ideas =

See [[Talk:GRASS SoC Ideas 2008]]

= Accepted Ideas =

GRASS SoC Ideas 2008

2008-03-12T19:17:19Z

⚠️Wolf: /* Ideas */ Added some ideas, we have been talking about

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

* For inspiration see the [[GRASS SoC Ideas 2007]] page

= Timeline =
* Community bonding time (getting to know the students)
* Work Begins
* Midterm evaluation
* Pencils down!

= Required Steps =

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* YYY: Accepted Students Announced
* SVN branches and access for students
* Coding begins...
* Students and mentors: Complete the Mid-term survey.
* Final commit and packaging for Google.

= Ideas =

Ideas with assigned mentors will be listed here. (will link to new page if needed)

===wxPython===
These project ideas have to do with the new GUI of GRASS

====3D Visualization====
GRASS has an old Tcl based n-dimensional visualization tool. However since we are moving over to the new wxPython-based GUI we will need something similar for the new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Color management====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.
# For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====SQL====
GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

====Kriging====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to grate a GUI (in wxPython) that can:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# Do Kriging based or R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton

==== Cartography ====
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates postscript maps. This would be a first step towards a graphical cartography tool for GRASS

'''Willing to Mentor:''' Michael Barton, Hamish Bowman

==== v.what ====
Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

'''Willing to Mentor:''' Michael Barton

=== Raster ===
These projects involve the GRASS raster library.

====r.external====
GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side on is unfortunately limited to importing raster maps.

Your job would be to create this r.external too for GRASS.
* See the [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal] for more information.

This project will be done in cooperation with GDAL.

'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

==== Raster Database ====
In GRASS vector maps can be connected to a database table as an attribute table. Many commercial GIS packages also allow this for raster maps.

Your job would be to implement this connection.

'''Willing to Mentor:''' Wolf Bergenheim

==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

=== Vector ===
These ideas relate to the Vector library of GRASS.

==== v.buffer and v.parallel ====
These two modules are broken and need to be reimplemented.

'''Willing to Mentor:''' Wolf Bergenheim

==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
'''Willing to Mentor:''' Wolf Bergenheim

==== v.voronoi / v.delauny ====
These modules need to be reimplemented as they are quite old an sub-optimal. There are many good algorithms that can be used.

==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)
* merging
* exaggeration
* collapse
* point aggregation

'''Willing to Mentor:''' Wolf Bergenheim

==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

'''Willing to Mentor:''' Wolf Bergenheim

==== Uniforming vector modules ====
GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS

'''Willing to Mentor:''' Wolf Bergenheim

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Suggested Ideas =

See [[Talk:GRASS SoC Ideas 2008]]

= Accepted Ideas =

Talk:GRASS SoC Ideas 2008

2008-03-12T07:25:57Z

⚠️Wolf: /* Line of sight */

Okay, making a raw dump of ideas here, so that we can more easily keep track of them.

= Displaced symbols =
*Create a module to place map symbols on a map, so that the feature and other overlap information is minimized (NP-Complete problem). The map symbol should be referenced to their original location, by using a reference line.
** Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.
** Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.
'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

: --HB: ''[http://thread.gmane.org/gmane.comp.gis.grass.devel/25006/focus=25584 see comments posted to the mailing list]''

= Uniforming the vector modules =
* Vector 3D support. Make all vector modules work in 3D space.
* Add where= and cats= to as many modules as possible, where reasonable (also see ml discussion on this)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Line of sight =
* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related): line of sight in 3D vector city models etc
* See [[GRASS SoC Ideas 2007]]

= wxGui =
* Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?
* create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]
* I've heard many complaints about GRASS lacking a Kriging module. One of these ideas could fix that (maybe both)
** gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)
** The same except would create an R script.
'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

Are these projects large enough to be their own individual SoC projects or should they maybe be one?

= Raster =

* GDAL based live-linking of raster maps to avoid import: r.external (from last year) via GDAL

* raster db connections. The raster category value would be a cat in a database. Introduce maybe a new kind of map otherwise identical to an INT map, but the values should be treated as DB cat id's.
** is this at all feasible?
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Vector =
* Implement new TIN algorithms from http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* reimplement v.delauny (also possibly by going via some other data structure)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Statistics =

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with OO.o on this one, e.g. one mentor form each organisation)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Ideas by Moriz Lennert =
== Implement file based spatial index ==

* (see "Keep topology and spatial index in file instead of in memory" in Radim's Vector ToDo http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)
* extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

== More ambitious ==
* implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

= Ideas by Helena Mitasova =
* Getting a start for the next generation visualization tool for GRASS - just a simple demo that can be done in 3 months to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS. Do we have a potential mentor? (I can be the second mentor, but we would need somebody to mentor the programming part).

= Ideas by Michael Barton =
* v.what to take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).
** '''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

GRASS SoC Ideas 2008

2008-02-22T07:41:27Z

⚠️Wolf:

= About =
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* Community bonding time (getting to know the students)
* Work Begins
* Midterm evaluation
* Pencils down!

= Required Steps =

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* YYY: Accepted Students Announced
* SVN branches and access for students
* Coding begins...
* Students and mentors: Complete the Mid-term survey.
* Final commit and packaging for Google.

= Ideas =

Ideas with assigned mentors will be listed here. (will link to new page if needed)

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

Talk:GRASS SoC Ideas 2008

2008-02-22T07:39:33Z

⚠️Wolf: /* wxGui */

Okay, making a raw dump of ideas here, so that we can more easily keep track of them.

= Displaced symbols =
*Create a module to place map symbols on a map, so that the feature and other overlap information is minimized (NP-Complete problem). The map symbol should be referenced to their original location, by using a reference line.
** Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.
** Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.
'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Uniforming the vector modules =
* Vector 3D support. Make all vector modules work in 3D space.
* Add where= and cats= to as many modules as possible, where reasonable (also see ml discussion on this)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Line of sight =
* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)
* See [GRASS SoC Ideas 2007]

= wxGui =
* Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?
* create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]
* I've heard many complaints about GRASS lacking a Kriging module. One of these ideas could fix that (maybe both)
** gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)
** The same except would create an R script.
'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

Are these projects large enough to be their own individual SoC projects or should they maybe be one?

= other =

* raster db connections. The raster category value would be a cat in a database. Introduce maybe a new kind of map otherwise identical to an INT map, but the values should be treated as DB cat id's.
** is this at all feasible?
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* Implement new TIN algorithms from http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* reimplement v.delauny (also possibly by going via some other data structure)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with OO.o on this one, e.g. one mentor form each organisation)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* r.external (from last year) via GDAL

= Ideas by Moriz Lennert =
== implement file based spatial index ==
* (see "Keep topology and spatial index in file instead of in memory" in Radim's Vector ToDo http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)
* extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

== More ambitious ==
* implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

= Ideas by Helena Mitasova =
* Getting a start for the next generation visualization tool for GRASS - just a simple demo that can be done in 3 months to display surface(s) in 2D and smoothly transfer the view into 3D. Do we have a potential mentor? (I can be the second mentor, but we would need somebody to mentor the programming part).

= Ideas by Michael Barton =
* v.what to take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).
** '''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

Talk:GRASS SoC Ideas 2008

2008-02-22T07:36:36Z

⚠️Wolf:

Okay, making a raw dump of ideas here, so that we can more easily keep track of them.

= Displaced symbols =
*Create a module to place map symbols on a map, so that the feature and other overlap information is minimized (NP-Complete problem). The map symbol should be referenced to their original location, by using a reference line.
** Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.
** Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.
'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Uniforming the vector modules =
* Vector 3D support. Make all vector modules work in 3D space.
* Add where= and cats= to as many modules as possible, where reasonable (also see ml discussion on this)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= Line of sight =
* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)
* See [GRASS SoC Ideas 2007]

= wxGui =
* Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?
* create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]
* I've heard many complaints about GRASS lacking a Kriging module. One of these ideas could fix that (maybe both)
** gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)
** The same except would create an R script.
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

= other =

* raster db connections. The raster category value would be a cat in a database. Introduce maybe a new kind of map otherwise identical to an INT map, but the values should be treated as DB cat id's.
** is this at all feasible?
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* Implement new TIN algorithms from http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* reimplement v.delauny (also possibly by going via some other data structure)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with OO.o on this one, e.g. one mentor form each organisation)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

* r.external (from last year) via GDAL

= Ideas by Moriz Lennert =
== implement file based spatial index ==
* (see "Keep topology and spatial index in file instead of in memory" in Radim's Vector ToDo http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)
* extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

== More ambitious ==
* implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)

= Ideas by Helena Mitasova =
* Getting a start for the next generation visualization tool for GRASS - just a simple demo that can be done in 3 months to display surface(s) in 2D and smoothly transfer the view into 3D. Do we have a potential mentor? (I can be the second mentor, but we would need somebody to mentor the programming part).

= Ideas by Michael Barton =
* v.what to take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).
** '''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

GRASS SoC Ideas

2008-02-21T23:46:59Z

⚠️Wolf:

#REDIRECT [[GRASS SoC Ideas 2008]]

GRASS SoC Ideas

2008-02-21T23:46:22Z

⚠️Wolf:

#REDIRECT [[GRASS SoC Ideas 2008]]

[[GRASS SoC Ideas 2008]]
[[GRASS SoC Ideas 2007]]

Talk:GRASS SoC Ideas 2008

2008-02-21T23:45:21Z

⚠️Wolf:

Okay, making a raw dump of ideas here, so that we can more easily keep track of them.

= Displaced symbols =
*Create a module to place map symbols on a map, so that the feature and other overlap information is minimized (NP-Complete problem). The map symbol should be referenced to their original location, by using a reference line.
** Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.
** Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

= Uniforming the vector modules =
** Vector 3D support. Make all vector modules work in 3D space.
** Add where= and cats= to as many modules as possible, where reasonable (also see ml discussion on this)
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

= Line of sight =
* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)
* See [GRASS SoC Ideas 2007]

= wxGui =
* Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?
* create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]
* I've heard many complaints about GRASS lacking a Kriging module. One of these ideas could fix that (maybe both)
* gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)
* The same except would create an R script.
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

= other =

* raster db connections. The raster category value would be a cat in a database. Introduce maybe a new kind of map otherwise identical to an INT map, but the values should be treated as DB cat id's.
** is this at all feasible?
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

* Implement new TIN algorithms from
http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

* Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

* reimplement v.delauny (also possibly by going via some other data structure)
'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with OO.o on this one, e.g. one mentor form each organisation)

* r.external (from last year) via GDAL

= Ideas by Moriz Lennert =
== implement file based spatial index ==
* (see "Keep topology and spatial index in file instead of in memory" in Radim's Vector ToDo http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)
* extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

More ambitious:
* implement an equivalent of eCognition's object-based classification (in
contrast to pixel-based classification)

= Ideas by Helena Mitasova =
Getting a start for the next generation visualization tool for GRASS - just a simple demo that can be done in 3 months to display surface(s) in 2D and smoothly transfer the view into 3D. Do we have a potential mentor? (I can be the second mentor, but we would need somebody to mentor the programming part).

= Ideas by Michael Barton =
* v.what to take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

GRASS SoC Ideas 2008

2008-02-21T23:22:24Z

⚠️Wolf:

= About =
This is the GRASS page for [Google Summer of Code http://wiki.osgeo.org/index.php/Google_Summer_of_Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.

= Timeline =
* Community bonding time (getting to know the students)
* Work Begins
* Midterm evaluation
* Pencils down!

= Required Steps =

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Process Student Applications. Deadline XXX
* YYY: Accepted Students Announced
* SVN branches and access for students
* Coding begins...
* Students and mentors: Complete the Mid-term survey.
* Final commit and packaging for Google.

= Ideas =

Ideas with assigned mentors will be listed here. (will link to new page if needed)

= Guidelines for Students =

How do you maximize your chances of getting picked? First read the [Google SoC FAQ http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).

= Accepted Ideas =

GRASS SoC Ideas

2008-02-20T13:55:09Z

⚠️Wolf: GRASS SoC Ideas moved to GRASS SoC Ideas 2007: New 2008 SoC ideas page will be arriving soon!

#REDIRECT [[GRASS SoC Ideas 2007]]

GRASS SoC Ideas 2007

2008-02-20T13:55:09Z

⚠️Wolf: GRASS SoC Ideas moved to GRASS SoC Ideas 2007: New 2008 SoC ideas page will be arriving soon!

GRASS related ideas for the [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2007:

==Timeline / Requirements for GRASS project==

* [http://code.google.com/support/bin/topic.py?topic=10442 Google SoC FAQ]

* Monday March 12th 2007, Deadline for '''OSGeo''' submission as an organization
* We must list of potential mentors for GRASS work
* March 24: Student application deadline.
* April 9: Accepted student applications announced.
* May 28: Students begin work.
* August 31: final evaluation deadline.

==Improved Line of Sight Analysis in GRASS==

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

; Potential Mentor: Paul Kelly

==A new module which would do line generalization with one of these algorithms==
* Douglas-Peuker algorithm
* Reumann-Witkam algorithm
* Lang simplification algorithm
* Cromley's Hierarchical algorithm
* Boyle's forward-looking smoothing algorithm
The most famous of these is the Douglas-Peuker algorithm.

This work will involve the use of the vector library to read the vector maps to be generalized and writing the new as a new vector map.

; Potential Mentor: Wolf Bergenheim

; Google [http://code.google.com/soc/osgeo/appinfo.html?csaid=3D7195C3927C616D Abstract]

==A new simulation/optimization algorithm for least cost path==
*A new module which would calculate the shortest path from a starting point to a destination. It would use dijkstra's algorithm do find the shortest path in a weighted network. In other words it would treat a cost surface (generated by r.cost) as a network and then calculate the shortest path. This differs from r.drain in that r.drain is a local function, greedy algorithm, whereas this a focal algorithm, that is it takes not only it's immediate location into account, and finds a global shortest path.

This will involve reading and writing raster maps.

; Potential Mentor: Wolf Bergenheim

==Shortest path in free (vector) space (avoiding obstacles)==
This module would take as input a vector map with polygons. These polygons would be treated as obstacles. It would also take a starting and end point as input. It would output a vector map containing the shortest path in free space (this assumes an equal cost surface). There are 2 different ways to do this calculation:
* by building a "road network" with the help of building trapezoids from each corner point of the obstacles.
OR PREFERABLY
* by building a visibility graph and converting it into a weighted network and running Dijkstra's shortest path on it.

This project will be vector and will also involve the directed graph library when calculating the shortest path.

; Potential Mentor: Wolf Bergenheim

; Google [http://code.google.com/soc/osgeo/appinfo.html?csaid=FEF51B36978B92BF Abstract]

==Further work on r.li==
The r.li module recently entered official GRASS code base. It is meant as a faster and more manageable replacement for r.le for the analysis of landscape ecology and composition. To replace it fully, we need:
* implementation of other indices
* remove the dependency on TclTk, so as to prepare it for the coming python GUI
* further testing and bugfixing

; Potential Mentor: Paolo Cavallini

== Other ideas ==
* better implement PostGIS support (I do not think this is very useful --[[User:Cavallini|Cavallini]] 07:48, 13 March 2007 (CET))
* integrate GDAL as part of GRASS raster library: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
: is this somewhat similar to a "r.external" equivalent of v.external? --[[User:Cavallini|Cavallini]] 07:48, 13 March 2007 (CET)
:: yes -- Markus [[User:Neteler|Neteler]] 15:03, 13 March 2007 (CET)
* implement parts of [[Time series in GRASS]]

== Potential Mentors ==

* Paul Kelly (for line of sight project)
* Wolf Bergenheim (for the line generalization / least cost projects)
* Paolo Cavallini (for r.li project)

== See also ==

* [http://wiki.osgeo.org/index.php/Google_Summer_of_Code OSGeo involvement Google Summer of Code]

[[Category:Development]]

GRASS SoC Ideas 2007

2007-03-12T12:16:00Z

⚠️Wolf: Formatted page to give each detailed project it's own section

GRASS related ideas for the [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2007:

==Improved Line of Sight Analysis in GRASS==

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

; Potential Mentor: Paul Kelly

==A new module which would do line generalization with one of these algorithms==
* Douglas-Peuker algorithm
* Reumann-Witkam algorithm
* Lang simplification algorithm
* Cromley's Hierarchical algorithm
* Boyle's forward-looking smoothing algorithm
The most famous of these is the Douglas-Peuker algorithm.

This work will involve the use of the vector library to read the vector maps to be generalized and writing the new as a new vector map.

; Potential Mentor: Wolf Bergenheim

==A new simulation/optimization algorithm for least cost path==
*A new module which would calculate the shortest path from a starting point to a destination. It would use dijkstra's algorithm do find the shortest path in a weighted network. In other words it would treat a cost surface (generated by r.cost) as a network and then calculate the shortest path. This differs from r.drain in that r.drain is a local function, greedy algorithm, whereas this a focal algorithm, that is it takes not only it's immediate location into account, and finds a global shortest path.

This will involve reading and writing raster maps.

; Potential Mentor: Wolf Bergenheim

==Shortest path in free (vector) space (avoiding obstacles)==
This module would take as input a vector map with polygons. These polygons would be treated as obstacles. It would also take a starting and end point as input. It would output a vector map containing the shortest path in free space (this assumes an equal cost surface). There are 2 different ways to do this calculation:
* by building a "road network" with the help of building trapezoids from each corner point of the obstacles.
OR PREFERABLY
* by building a visibility graph and converting it into a weighted network and running Dijkstra's shortest path on it.

This project will be vector and will also involve the directed graph library when calculating the shortest path.

; Potential Mentor: Wolf Bergenheim

==Other==
* carry on the work on r.li --[[User:Cavallini|Cavallini]] 14:37, 27 February 2007 (CET)
* better implement PostGIS support
* integrate GDAL as part of GRASS raster library: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)
* Wolf Bergenheim (for the line generalization / least cost projects)

== See also ==

* [http://wiki.osgeo.org/index.php/Google_Summer_of_Code OSGeo involvement Google Summer of Code]

[[Category:Development]]

GRASS SoC Ideas 2007

2007-03-12T12:00:02Z

⚠️Wolf:

GRASS related ideas for the [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2007:

* '''Improved Line of Sight Analysis in GRASS'''

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

; Potential Mentor: Paul Kelly

* '''A new module which would do line generalization with one of these algorithms'''
** Douglas-Peuker algorithm
** Reumann-Witkam algorithm
** Lang simplification algorithm
** Cromley's Hierarchical algorithm
** Boyle's forward-looking smoothing algorithm
The most famous of these is the Douglas-Peuker algorithm.
; Potential Mentor: Wolf Bergenheim

* '''A new simulation/optimization algorithm for least cost path'''
**A new module which would calculate the shortest path from a starting point to a destination. It would use dijkstra's algorithm do find the shortest path in a weighted network. In other words it would treat a cost surface (generated by r.cost) as a network and then calculate the shortest path. This differs from r.drain in that r.drain is a local function, greedy algorithm, whereas this a focal algorithm, that is it takes not only it's immediate location into account, and finds a global shortest path.
; Potential Mentor: Wolf Bergenheim

* '''Shortest path in free (vector) space (avoiding obstacles)'''
This module would take as input a vector map with polygons. These polygons would be treated as obstacles. It would also take a starting and end point as input. It would output a vector map containing the shortest path in free space (this assumes an equal cost surface). There are 2 different ways to do this calculation:
** by building a "road network" with the help of building trapezoids from each corner point of the obstacles.
** by building a visibility graph and converting it into a weighted network and running Dijkstra's shortest path on it.
; Potential Mentor: Wolf Bergenheim

* carry on the work on r.li --[[User:Cavallini|Cavallini]] 14:37, 27 February 2007 (CET)
* better implement PostGIS support
* integrate GDAL as part of GRASS raster library: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)
* Wolf Bergenheim (for the line generalization / least cost projects)

=== See also ===

* [http://wiki.osgeo.org/index.php/Google_Summer_of_Code OSGeo involvement Google Summer of Code]

[[Category:Development]]

GRASS SoC Ideas 2007

2007-03-12T11:58:10Z

⚠️Wolf: /* Potential Mentors */

GRASS related ideas for the [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2007:

* '''Improved Line of Sight Analysis in GRASS'''

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

; Potential Mentor: Paul Kelly

* '''A new module which would do line generalization with one of these algorithms'''
** Douglas-Peuker algorithm
** Reumann-Witkam algorithm
** Lang simplification algorithm
** Cromley's Hierarchical algorithm
** Boyle's forward-looking smoothing algorithm
The most famous of these is the Douglas-Peuker algorithm.
; Potential Mentor: Wolf Bergenheim

* '''A new simulation/optimization algorithm for least cost path'''
**A new module which would calculate the shortest path from a starting point to a destination. It would use dijkstra's algorithm do find the shortest path in a weighted network. In other words it would treat a cost surface (generated by r.cost) as a network and then calculate the shortest path. This differs from r.drain in that r.drain is a local function, greedy algorithm, whereas this a focal algorithm, that is it takes not only it's immediate location into account, and finds a global shortest path.
; Potential Mentor: Wolf Bergenheim

* '''Shortest path in free (vector) space (avoiding obstacles'''
This module would take as input a vector map with polygons. These polygons would be treated as obstacles. It would also take a starting and end point as input. It would output a vector map containing the shortest path in free space (this assumes an equal cost surface). There are 2 different ways to do this calculation:
** by building a "road network" with the help of building trapezoids from each corner point of the obstacles.
** by building a visibility graph and converting it into a weighted network and running Dijkstra's shortest path on it.
; Potential Mentor: Wolf Bergenheim

* carry on the work on r.li --[[User:Cavallini|Cavallini]] 14:37, 27 February 2007 (CET)
* better implement PostGIS support
* integrate GDAL as part of GRASS raster library: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)
* Wolf Bergenheim (for the line generalization / least cost projects)

=== See also ===

* [http://wiki.osgeo.org/index.php/Google_Summer_of_Code OSGeo involvement Google Summer of Code]

[[Category:Development]]

GRASS SoC Ideas 2007

2007-03-12T11:55:27Z

⚠️Wolf:

GRASS related ideas for the [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2007:

* '''Improved Line of Sight Analysis in GRASS'''

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003:
http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf
Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Some hints on what's involved in GRASS programming are available here: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/SUBMITTING

; Potential Mentor: Paul Kelly

* '''A new module which would do line generalization with one of these algorithms'''
** Douglas-Peuker algorithm
** Reumann-Witkam algorithm
** Lang simplification algorithm
** Cromley's Hierarchical algorithm
** Boyle's forward-looking smoothing algorithm
The most famous of these is the Douglas-Peuker algorithm.
; Potential Mentor: Wolf Bergenheim

* '''A new simulation/optimization algorithm for least cost path'''
**A new module which would calculate the shortest path from a starting point to a destination. It would use dijkstra's algorithm do find the shortest path in a weighted network. In other words it would treat a cost surface (generated by r.cost) as a network and then calculate the shortest path. This differs from r.drain in that r.drain is a local function, greedy algorithm, whereas this a focal algorithm, that is it takes not only it's immediate location into account, and finds a global shortest path.
; Potential Mentor: Wolf Bergenheim

* '''Shortest path in free (vector) space (avoiding obstacles'''
This module would take as input a vector map with polygons. These polygons would be treated as obstacles. It would also take a starting and end point as input. It would output a vector map containing the shortest path in free space (this assumes an equal cost surface). There are 2 different ways to do this calculation:
** by building a "road network" with the help of building trapezoids from each corner point of the obstacles.
** by building a visibility graph and converting it into a weighted network and running Dijkstra's shortest path on it.
; Potential Mentor: Wolf Bergenheim

* carry on the work on r.li --[[User:Cavallini|Cavallini]] 14:37, 27 February 2007 (CET)
* better implement PostGIS support
* integrate GDAL as part of GRASS raster library: [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" proposal]
* integrate OGR as part of GRASS vector library
:''please expand, I don't understand what you mean'' -HB

== Potential Mentors ==

* Paul Kelly (for line of sight project)

=== See also ===

* [http://wiki.osgeo.org/index.php/Google_Summer_of_Code OSGeo involvement Google Summer of Code]

[[Category:Development]]