GRASS SoC Ideas 2013 - Revision history

⚠️HamishBowman: /* Accepted Ideas */ + trac wiki link

2013-05-28T21:16:57Z

Accepted Ideas: + trac wiki link

← Older revision		Revision as of 21:16, 28 May 2013
Line 179:		Line 179:

	== Accepted Ideas ==		== Accepted Ideas ==

			* See also the [https://trac.osgeo.org/grass/wiki/SoCProjects Trac wiki]

	# ''GRASS GIS Interactive Scatter Plot Tool'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/turek/68001 abstract])		# ''GRASS GIS Interactive Scatter Plot Tool'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/turek/68001 abstract])

⚠️HamishBowman: /* Accepted Ideas */ +backup mentors

2013-05-28T21:07:24Z

Accepted Ideas: +backup mentors

← Older revision		Revision as of 21:07, 28 May 2013
Line 183:		Line 183:
	#: Student: Stepan Turek		#: Student: Stepan Turek
	#: Mentor: Martin Landa		#: Mentor: Martin Landa
	#: Backup mentors: ?		#: Backup mentors: Michael Barton
	#: Wiki page: [[GRASS GSoC 2013 GRASS GIS Interactive Scatter Plot Tool]]		#: Wiki page: [[GRASS GSoC 2013 GRASS GIS Interactive Scatter Plot Tool]]
			#:
	# ''Temporal GIS Algebra for raster and vector data in GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/mastho/5001 abstract])		# ''Temporal GIS Algebra for raster and vector data in GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/mastho/5001 abstract])
	#: Student: Thomas Leppelt		#: Student: Thomas Leppelt
	#: Mentor: Sören Gebbert		#: Mentor: Sören Gebbert
	#: Backup ~~mentor~~: ?		#: Backup mentors: Helena Mitasova & Michael Barton
	#: Wiki page: [[GRASS GSoC 2013 Temporal GIS Algebra for raster and vector data in GRASS]]		#: Wiki page: [[GRASS GSoC 2013 Temporal GIS Algebra for raster and vector data in GRASS]]
			#:
	# ''An Implementation of Horizon Based Stratigraphy for GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/timb/11001 abstract])		# ''An Implementation of Horizon Based Stratigraphy for GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/timb/11001 abstract])
	#: Student: Tim Bailey		#: Student: Tim Bailey
	#: Mentor: Benjamin Ducke		#: Mentor: Benjamin Ducke
	#: Backup mentors: ?		#: Backup mentors: Michael Barton, Sören Gebbert, & Hamish Bowman
	#: Wiki page: [[GRASS GSoC 2013 An Implementation of Horizon Based Stratigraphy for GRASS]]		#: Wiki page: [[GRASS GSoC 2013 An Implementation of Horizon Based Stratigraphy for GRASS]]

⚠️Landa: /* Accepted Ideas */

2013-05-27T21:14:54Z

Accepted Ideas

← Older revision		Revision as of 21:14, 27 May 2013
Line 187:		Line 187:
	# ''Temporal GIS Algebra for raster and vector data in GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/mastho/5001 abstract])		# ''Temporal GIS Algebra for raster and vector data in GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/mastho/5001 abstract])
	#: Student: Thomas Leppelt		#: Student: Thomas Leppelt
	#: Mentor:		#: Mentor: Sören Gebbert
	#: Backup mentor:		#: Backup mentor: ?
	#: Wiki page: [[GRASS GSoC 2013 Temporal GIS Algebra for raster and vector data in GRASS]]		#: Wiki page: [[GRASS GSoC 2013 Temporal GIS Algebra for raster and vector data in GRASS]]
	# ''An Implementation of Horizon Based Stratigraphy for GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/timb/11001 abstract])		# ''An Implementation of Horizon Based Stratigraphy for GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/timb/11001 abstract])
	#: Student: Tim Bailey		#: Student: Tim Bailey
	#: Mentor:		#: Mentor: Benjamin Ducke
	#: Backup mentors:		#: Backup mentors: ?
	#: Wiki page: [[GRASS GSoC 2013 An Implementation of Horizon Based Stratigraphy for GRASS]]		#: Wiki page: [[GRASS GSoC 2013 An Implementation of Horizon Based Stratigraphy for GRASS]]

⚠️Landa: accepted ideas

2013-05-27T21:11:29Z

accepted ideas

← Older revision		Revision as of 21:11, 27 May 2013
Line 177:		Line 177:

	http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html		http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html

			== Accepted Ideas ==

			# ''GRASS GIS Interactive Scatter Plot Tool'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/turek/68001 abstract])
			#: Student: Stepan Turek
			#: Mentor: Martin Landa
			#: Backup mentors: ?
			#: Wiki page: [[GRASS GSoC 2013 GRASS GIS Interactive Scatter Plot Tool]]
			# ''Temporal GIS Algebra for raster and vector data in GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/mastho/5001 abstract])
			#: Student: Thomas Leppelt
			#: Mentor:
			#: Backup mentor:
			#: Wiki page: [[GRASS GSoC 2013 Temporal GIS Algebra for raster and vector data in GRASS]]
			# ''An Implementation of Horizon Based Stratigraphy for GRASS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2013/timb/11001 abstract])
			#: Student: Tim Bailey
			#: Mentor:
			#: Backup mentors:
			#: Wiki page: [[GRASS GSoC 2013 An Implementation of Horizon Based Stratigraphy for GRASS]]

⚠️HamishBowman: /* Python */ willing to mentors

2013-05-16T10:44:46Z

Python: willing to mentors

← Older revision		Revision as of 10:44, 16 May 2013
Line 35:		Line 35:

	* GRASS magic extension for the IPython Notebook: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/panwar9/1		* GRASS magic extension for the IPython Notebook: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/panwar9/1
	'''Willing to Mentor:'''		'''Willing to Mentor:''' Massimo Di Stefano, Anna Petrasova

	=== Symbology / Cartography ===		=== Symbology / Cartography ===

Neteler: /* Ideas */ +GRASS magic extension for the IPython Notebook

2013-05-03T19:26:51Z

Ideas: +GRASS magic extension for the IPython Notebook

← Older revision		Revision as of 19:26, 3 May 2013
Line 16:		Line 16:

	=== General ===		=== General ===

	* Implement a buffered binary balanced search tree using external memory: Rationale: some modules and library functions use a binary search tree, which can lead to out-of-memory errors for large datasets. A buffered binary balanced search tree using external memory would solve this problem and enhance the capability of GRASS to work with large datasets on limited hardware resources.

	* [[Parallel_GRASS_jobs\|Parallelize]] CPU-heavy modules using [[OpenMP]], OpenCL ([[GPU]]), and/or pthreads.

	* If you're really stuck for ideas, [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=owner&col=priority&col=milestone&type=enhancement hunt around the wish list in the trac system].		* If you're really stuck for ideas, [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=owner&col=priority&col=milestone&type=enhancement hunt around the wish list in the trac system].
Line 28:		Line 24:
	* Improve and fix bugs in the QGIS GRASS Toolbox. Generally make it smoother to pass projects and workflows between the two.		* Improve and fix bugs in the QGIS GRASS Toolbox. Generally make it smoother to pass projects and workflows between the two.
	: Or simply use [[GRASS and Sextante\|Sextante plugin in QGIS]] which does this already		: Or simply use [[GRASS and Sextante\|Sextante plugin in QGIS]] which does this already

			=== GRASS GIS core improvements ===

			* Implement a buffered binary balanced search tree using external memory: Rationale: some modules and library functions use a binary search tree, which can lead to out-of-memory errors for large datasets. A buffered binary balanced search tree using external memory would solve this problem and enhance the capability of GRASS to work with large datasets on limited hardware resources.

			* [[Parallel_GRASS_jobs\|Parallelize]] CPU-heavy modules using [[OpenMP]], OpenCL ([[GPU]]), and/or pthreads.
			'''Willing to Mentor:'''

			=== Python ===

			* GRASS magic extension for the IPython Notebook: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/panwar9/1
			'''Willing to Mentor:'''

	=== Symbology / Cartography ===		=== Symbology / Cartography ===
Line 36:		Line 44:
	:: ''note that SoC only accepts coding projects, not graphics design or documentation projects.''		:: ''note that SoC only accepts coding projects, not graphics design or documentation projects.''
	:* Add svg/eps support to a d.* module and {{Cmd\|ps.map}} would be quite helpful. See the {{Cmd\|d.graph}} help page and {{Cmd\|ps.map}}'s "eps" and "vpoints" instructions. The first step would be to write a stand-alone tool in C to create d.graph commands; the second step would be to add as a new option in ''d.graph''; a third step would be to backport this to GRASS 6's graphics API. See also {{trac\|733}} wish re. implementing Bézier curves in the display drivers.		:* Add svg/eps support to a d.* module and {{Cmd\|ps.map}} would be quite helpful. See the {{Cmd\|d.graph}} help page and {{Cmd\|ps.map}}'s "eps" and "vpoints" instructions. The first step would be to write a stand-alone tool in C to create d.graph commands; the second step would be to add as a new option in ''d.graph''; a third step would be to backport this to GRASS 6's graphics API. See also {{trac\|733}} wish re. implementing Bézier curves in the display drivers.
	:: '''Willing to co-mentor:''' Hamish		:: '''Willing to co-mentor:''' Hamish Bowman

	* Rework the complete set of thematic cartography tools such as {{Cmd\|d.vect.thematic}} and {{Cmd\|d.thematic.area}} and the related classification routines. This would comprise:		* Rework the complete set of thematic cartography tools such as {{Cmd\|d.vect.thematic}} and {{Cmd\|d.thematic.area}} and the related classification routines. This would comprise:
Line 47:		Line 55:
	:* Generalized ASCII table input for {{Cmd\|d.legend}} (see {{trac\|89}} wish)		:* Generalized ASCII table input for {{Cmd\|d.legend}} (see {{trac\|89}} wish)
	:* Histogram sidebar support for {{Cmd\|d.legend}} and {{Cmd\|ps.map}} (see {{trac\|1049}} wish)		:* Histogram sidebar support for {{Cmd\|d.legend}} and {{Cmd\|ps.map}} (see {{trac\|1049}} wish)
	:: '''Willing to co-mentor d.legend bits:''' Hamish		:: '''Willing to co-mentor d.legend bits:''' Hamish Bowman

	=== Imagery ===		=== Imagery ===

⚠️Huhabla: /* Temporal GIS Algebra for raster and vector data */

2013-05-02T11:39:38Z

Temporal GIS Algebra for raster and vector data

← Older revision		Revision as of 11:39, 2 May 2013
Line 81:		Line 81:

	* Spatio-temporal vector algebra module <b>t.vect.mapcalc</b>		* Spatio-temporal vector algebra module <b>t.vect.mapcalc</b>
	** The algebra will be based on vector map operations provided from {{Cmd\|v.overlay}} (and, or, xor, not), {{Cmd\|v.buffer}} (buff_point, buff_line, buff_area), {{Cmd\|v.patch}} (patch), ... , temporal variables (day of year, weekday, datum, time, ...) ~~and~~ temporal topology relations (predecessor, successor, follows, equals, ...)		** The algebra will be based on vector map operations provided from {{Cmd\|v.overlay}} (and, or, xor, not), {{Cmd\|v.buffer}} (buff_point, buff_line, buff_area), {{Cmd\|v.patch}} (patch), ... , temporal variables (day of year, weekday, datum, time, ...), temporal topology relations (predecessor, successor, follows, equals, ...) and spatial topology relations (equivalent, in, disjoint, ..)
	** The resulting module will be able to process space time vector datasets using expressions like:		** The resulting module will be able to process space time vector datasets using expressions like:

Line 112:		Line 112:

	* Spatio-temporal raster algebra module <b>t.rast.mapcalc</b>		* Spatio-temporal raster algebra module <b>t.rast.mapcalc</b>
	** The algebra will be based on the existing {{Cmd\|r.mapcalc}} raster map algebra, temporal variables (day of year, weekday, datum, time, ...) ~~and~~ temporal topology relations (predecessor, successor, follows, equals, ...)		** The algebra will be based on the existing {{Cmd\|r.mapcalc}} raster map algebra, temporal variables (day of year, weekday, datum, time, ...), temporal topology relations (predecessor, successor, follows, equals, ...) and spatial topology relations (equivalent, in, disjoint, ..)
	{{GSoC}}		{{GSoC}}
	** The resulting module will be able to process space time raster datasets using expressions like:		** The resulting module will be able to process space time raster datasets using expressions like:
Line 127:		Line 127:
	</source>		</source>

	* The GRASS GIS temporal framework will be utilized and the pygrass module interface		* The GRASS GIS temporal framework will be utilized and extened with the spatio-temporal algebra
			* The pygrass module interface will be used to call the raster mapcalc and vector overlay/buffer modules
	* PLY will be used for lexical analysis and parser generation		* PLY will be used for lexical analysis and parser generation
	* ~~Temporal~~ algebra will be equivalent for booth modules with about <b>60</b> internal variables and functions		* Spatio-temporal algebra will be equivalent for booth modules with about <b>60</b> internal variables and functions

	=== Improve GRASS' kriging and 3D interpolation capabilities ===		=== Improve GRASS' kriging and 3D interpolation capabilities ===

⚠️Benducke: /* Improve GRASS' kriging and 3D interpolation capabilities */

2013-05-02T09:05:30Z

Improve GRASS' kriging and 3D interpolation capabilities

← Older revision		Revision as of 09:05, 2 May 2013
Line 133:		Line 133:
	=== Improve GRASS' kriging and 3D interpolation capabilities ===		=== Improve GRASS' kriging and 3D interpolation capabilities ===

	One of GRASS' most outstanding features is its support for 3D raster (voxel) data.		One of GRASS' most outstanding features is its support for 3D raster (voxel) data. In fact, GRASS offers more functionality for 3D volumetric data processing than many expensive proprietary solutions. This GSoC project aims to improve on GRASS' existing strengths by significantly enhancing the methods for interpolation of data in voxel space. Currently, GRASS offers spline-based interpolation of 3D vector points to 3D voxel data. We plan to add the following (see also notes below):
	This GSoC project aims to significantly ~~enhance~~ the methods for interpolation data in voxel space.
	Currently, GRASS offers spline-based interpolation of 3D vector points to 3D voxel data.
	We plan to add the following:

	* 3D geostatistics/kriging		* 3D geostatistics/kriging
Line 142:		Line 139:
	* transition probability models (TBM)		* transition probability models (TBM)
	* stratigraphic modeling		* stratigraphic modeling

			These improved 3D interpolation capabilities would combine ideally with the 3D processing modules already present in GRASS (flexible 3D map algebra, export to VTK format for visualization, 3D vector data manipulation, etc.).

			If this project can be realized as planned, it will allow GRASS to establish itself as the open source tool of choice for applications in geology, geophysics, soil science and archaeology, all of which have a need to model subsurface soil structures and properties based on 3D sampling points. These areas of application are currently dominated by expensive and inflexible proprietary tools, which is why we feel that this project could make a real difference for open source users.

	'''Available mentors:'''		'''Available mentors:'''
Line 149:		Line 150:

	'''Notes on 3D kriging''':		'''Notes on 3D kriging''':
	Since GRASS currently lacks native geostatistical capabilities, this project will cover 3D 'and' 2D variograms, kriging interpolation, etc. There are already efforts underway in the GRASS community to supply ~~substantial,~~ geostatistical functionality and we expect ~~this project~~ to make full use of them (see [http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html]).		Since GRASS currently lacks native geostatistical capabilities, this project will cover 3D ''and'' 2D variograms, kriging interpolation, etc. There are already efforts underway in the GRASS community to supply complete geostatistical functionality and we expect our GSoC student to make full use of them (see [http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html]), minimzing the time this GSoC project will have to spent on the 3D kriging component.

	'''Notes on radial basis functions (RBF)''':		'''Notes on radial basis functions (RBF)''':
	RBF are straight-forward interpolation functions. Most GIS users will be aware of Inverse Distance Weighting, which is just one specific case of RBF. In 3D interpolation, RBF provide simple and efficient interpolators useful for dense 3D samples (or for producing incomplete models from sparse samples).		RBF are straight-forward interpolation functions. Most GIS users will be aware of Inverse Distance Weighting (e.g. GRASS has [http://grass.osgeo.org/grass70/manuals/v.surf.idw.html v.surf.idw]), which is just one specific case of RBF. In the context of 3D interpolation, RBF provide simple and efficient interpolators useful for dense 3D samples (or for producing incomplete models from sparse samples).

	'''Notes on transition probability models (TBM)''':		'''Notes on transition probability models (TBM)''':
	TBMs allow to interpolate category (integer) data, such as soil classes in 3D space. Naturally, the ~~results~~ of such an interpolation will not be as accurate ~~or useful~~ as that of interpolation continuous data via splines or kriging. However, soil horizons, layers ~~et al~~. are very common data in soil ~~sciences~~ and geology (~~bore hole~~ samples!) and there is currently no robust method for interpolating such data in GRASS. There is a FORTRAN implementation of TBM called T-PROGS (by Steven F. Carle) that is in the public domain. T-PROGS could be run from within GRASS as a command line tool or translated to C and converted into a "real" GRASS module (see [http://www.xmswiki.com/xms/GMS:T-PROGS]; see also [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;37&g=50]).		TBMs allow to interpolate category (integer) data, such as soil classes in 3D space. Naturally, the result of such an interpolation will not be as accurate as that of interpolation of continuous data via splines or kriging. However, soil horizons, layers etc. are very common data in soil science and geology (borehole samples!) and there is currently no robust method for interpolating such data in GRASS. There is a FORTRAN implementation of TBM called T-PROGS (by Steven F. Carle) that is in the public domain. T-PROGS could be run from within GRASS as a command line tool or translated to C and converted into a "real" GRASS module (see [http://www.xmswiki.com/xms/GMS:T-PROGS]; see also [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;37&g=50]).

	'''Notes on stratigraphic modeling''':		'''Notes on stratigraphic modeling''':
	Another approach to soil horizon interpolation, that may be easy to implement in GRASS is documented here: [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50].		Another approach to soil horizon interpolation, that may be easy to implement in GRASS, is documented here: [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50]. Basically, this involves taking 2D cross sections of soil horizons and extruding them into a 3D model in the most straight-forward way. This is something that is often done manually by soil scientists and archaeologists, but could be done more efficiently and transparently using a simple algorithm.

	See also these GRASS mailing list posts for further information:		See also these GRASS mailing list posts for further information:

⚠️Benducke: /* Improve GRASS' kriging and 3D interpolation capabilities */

2013-05-02T07:34:51Z

Improve GRASS' kriging and 3D interpolation capabilities

← Older revision		Revision as of 07:34, 2 May 2013
Line 146:		Line 146:

	* Benjamin Ducke		* Benjamin Ducke
			* Sören Gebbert

	'''Notes on 3D kriging''':		'''Notes on 3D kriging''':

⚠️Madi: /* Improve GRASS' kriging and 3D interpolation capabilities */

2013-05-02T06:53:41Z

Improve GRASS' kriging and 3D interpolation capabilities

← Older revision		Revision as of 06:53, 2 May 2013
Line 157:		Line 157:

	'''Notes on stratigraphic modeling''':		'''Notes on stratigraphic modeling''':
	Another approach to soil horizon interpolation, that may be easy to implement in GRASS is documented here: http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50.		Another approach to soil horizon interpolation, that may be easy to implement in GRASS is documented here: [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50].

	See also these GRASS mailing list posts for further information:		See also these GRASS mailing list posts for further information: