GRASS SoC Ideas 2008 - Revision history

⚠️Wenzeslaus: /* Cartography */

2014-02-06T04:25:14Z

Cartography

← Older revision		Revision as of 04:25, 6 February 2014
Line 81:		Line 81:
	'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert		'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert

	''Implemented outside GSoC as {{{Cmd\|g.gui.psmap}}.''		''Implemented outside GSoC as {{Cmd\|g.gui.psmap}}.''

	==== v.what ====		==== v.what ====

⚠️Wenzeslaus: /* Cartography */ g.gui.psmap

2014-02-06T04:22:46Z

Cartography: g.gui.psmap

← Older revision		Revision as of 04:22, 6 February 2014
Line 80:		Line 80:

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

			''Implemented outside GSoC as {{{Cmd\|g.gui.psmap}}.''

	==== v.what ====		==== v.what ====

⚠️Wenzeslaus: /* Raster Objects */ noting gsoc 2012

2014-01-31T05:16:08Z

Raster Objects: noting gsoc 2012

← Older revision		Revision as of 05:16, 31 January 2014
Line 153:		Line 153:

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

			''Implemented in [[GRASS GSoC 2012 Image Segmentation\|GSoC 2012]] as {{cmd\|i.segment\|version=70}} and improved later.''

	=== Vector ===		=== Vector ===

⚠️Wenzeslaus: /* Time series management in GRASS */ noting existence of tgrass

2014-01-31T05:09:45Z

Time series management in GRASS: noting existence of tgrass

← Older revision		Revision as of 05:09, 31 January 2014
Line 106:		Line 106:

	See details at [[Time series in GRASS]]		See details at [[Time series in GRASS]]

			''Implemented outside GSoC as GRASS Temporal Framework (see {{cmd\|temporalintro\|version=70}}).''

	====Improved Line of Sight Analysis (Completed outside of GSoC: r.viewshed, but see {{trac\|390}}) ====		====Improved Line of Sight Analysis (Completed outside of GSoC: r.viewshed, but see {{trac\|390}}) ====

⚠️Landa: /* Accepted Ideas */

2011-03-13T12:47:43Z

Accepted Ideas

← Older revision		Revision as of 12:47, 13 March 2011
Line 226:		Line 226:
	See: http://code.google.com/soc/2008/osgeo/about.html		See: http://code.google.com/soc/2008/osgeo/about.html

	~~[[Category:Development]]~~		{{GSoC}}
	~~[[Category:Community]]~~
	~~[[Category:~~ GSoC]]

⚠️HamishBowman: /* Kriging */

2009-08-26T07:58:23Z

Kriging

← Older revision		Revision as of 07:58, 26 August 2009
Line 143:		Line 143:
	: See v.autokridge in Addons		: See v.autokridge in Addons

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

			'''Assigned Student:''' [[V.krige_GSoC_2009\|Anne Ghisla]]

	==== Raster Objects ====		==== Raster Objects ====

Neteler: more updates about existing efforts

2009-03-14T06:26:44Z

more updates about existing efforts

← Older revision		Revision as of 06:26, 14 March 2009
Line 89:		Line 89:
	These projects involve the GRASS raster library.		These projects involve the GRASS raster library.

	====r.external: Virtual raster map linking ====		====r.external: Virtual raster map linking (completed outside of GSoc)====
	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.		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.

Line 101:		Line 101:
	====Time series management in GRASS====		====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].		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]]		See details at [[Time series in GRASS]]

	====Improved Line of Sight Analysis (~~Nearly complete~~: r.viewshed) ====		====Improved Line of Sight Analysis (Completed outside of GSoC: r.viewshed, but see {{trac\|390}}) ====

	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:		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:
Line 112:		Line 114:

	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).		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).

			: the authors of r.viewshed have a modified version which corresponds to r.cva

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

	==== Raster ~~Database~~ ====		==== Raster attribute management in SQL 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.		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 {{cmd\|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.
	<!-- Many proprietary GIS packages also allow this for raster maps. --HB: so what? -->		<!-- Many proprietary GIS packages also allow this for raster maps. --HB: so what? -->

Line 136:		Line 140:
	#* Call R to do variogram analysis. For efficiency the R environment should be done		#* 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.		#* Call R to do the actual Kriging. This includes importing the result back to GRASS.

			: See v.autokridge in Addons

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

	==== Raster Objects ====		==== 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.		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. While GRASS has {{cmd\|i.smap}} as segmentation algorithm this does not perform hierarchical classification. An idea might be to use the vector engine with topology for this.

	'''Willing to Mentor:''' Moritz Lennert (as second mentor for the contents, not the programming)		'''Willing to Mentor:''' Moritz Lennert (as second mentor for the contents, not the programming)
Line 167:		Line 173:
	Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.		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~~)		This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMaster)
	* merging		* merging
	* exaggeration		* exaggeration
Line 176:		Line 182:

	==== v.overlay ====		==== 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)		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). Support both topological (cut out) and simple features (take entire object) intersection and more.

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

	==== Uniforming vector modules ====		==== 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.		GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lack where= and cats= parameters.

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

⚠️HamishBowman: /* v.voronoi / v.delauny (Accepted) */

2009-03-14T02:07:04Z

v.voronoi / v.delauny (Accepted)

← Older revision		Revision as of 02:07, 14 March 2009
Line 159:		Line 159:
	'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert		'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert

	==== v.voronoi / v.delauny (Accepted) ====		==== v.voronoi / v.delauny (Accepted; Completed) ====
	These modules need to be reimplemented or deeply debugged as they are <!-- quite old and --HB: so what? --> sub-optimal. There are many good algorithms that can be used.		These modules need to be reimplemented or deeply debugged as they are <!-- quite old and --HB: so what? --> sub-optimal. There are many good algorithms that can be used.

⚠️HamishBowman: /* v.buffer and v.parallel (Accepted) */ done

2009-03-14T02:06:36Z

v.buffer and v.parallel (Accepted): done

← Older revision		Revision as of 02:06, 14 March 2009
Line 147:		Line 147:
	These ideas relate to the Vector library of GRASS.		These ideas relate to the Vector library of GRASS.

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

⚠️HamishBowman: /* Improved Line of Sight Analysis */

2009-03-14T01:56:04Z

Improved Line of Sight Analysis

← Older revision		Revision as of 01:56, 14 March 2009
Line 105:		Line 105:
	See details at [[Time series in GRASS]]		See details at [[Time series in GRASS]]

	====Improved Line of Sight Analysis====		====Improved Line of Sight Analysis (Nearly complete: r.viewshed) ====

	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:		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: