Talk:GRASS SoC Ideas 2008 - Revision history

⚠️Wolf: /* Line of sight */

2008-03-12T07:25:57Z

Line of sight

← Older revision		Revision as of 07:25, 12 March 2008
Line 18:		Line 18:
	* Improved line of sight (Paul Kelly's proposal from last year)		* 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		* 3D Vector line of sight (related): line of sight in 3D vector city models etc
	* See [GRASS SoC Ideas 2007]		* See [[GRASS SoC Ideas 2007]]

	= wxGui =		= wxGui =

⚠️HamishBowman: /* Displaced symbols */ comments

2008-03-11T05:40:37Z

Displaced symbols: comments

← Older revision		Revision as of 05:40, 11 March 2008
Line 6:		Line 6:
	** Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.		** 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>		'''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 =		= Uniforming the vector modules =

⚠️HamishBowman: /* implement file based spatial index */

2008-03-11T04:00:50Z

implement file based spatial index

← Older revision		Revision as of 04:00, 11 March 2008
Line 56:		Line 56:

	= Ideas by Moriz Lennert =		= Ideas by Moriz Lennert =
	== ~~implement~~ file based spatial index ==		== 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)		* (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)		* extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)

Neteler: 3D Vector line of sight: line of sight in 3D vector city models

2008-03-10T10:03:49Z

3D Vector line of sight: line of sight in 3D vector city models

← Older revision		Revision as of 10:03, 10 March 2008
Line 14:		Line 14:
	= Line of sight =		= Line of sight =
	* Improved line of sight (Paul Kelly's proposal from last year)		* Improved line of sight (Paul Kelly's proposal from last year)
	* 3D Vector line of sight (related)		* 3D Vector line of sight (related): line of sight in 3D vector city models etc
	* See [GRASS SoC Ideas 2007]		* See [GRASS SoC Ideas 2007]

⚠️Helena: /* Ideas by Helena Mitasova */

2008-03-08T02:18:55Z

Ideas by Helena Mitasova

← Older revision		Revision as of 02:18, 8 March 2008
Line 65:		Line 65:

	= Ideas by Helena Mitasova =		= 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).		* 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 =		= 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).		* 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>		** '''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

Neteler: more structure

2008-02-24T23:00:46Z

more structure

← Older revision		Revision as of 23:00, 24 February 2008
Line 27:		Line 27:
	Are these projects large enough to be their own individual SoC projects or should they maybe be one?		Are these projects large enough to be their own individual SoC projects or should they maybe be one?

	= ~~other~~ =		= 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.		* 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.
Line 33:		Line 35:
	**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>		**'''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)		* 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>		**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
Line 44:		Line 47:
	* reimplement v.delauny (also possibly by going via some other data structure)		* reimplement v.delauny (also possibly by going via some other data structure)
	**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>		**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

			= Statistics =

	* R integration [there was some talk on this on the list]		* R integration [there was some talk on this on the list]
Line 49:		Line 54:
	* 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)		* 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>		**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

	* r.external (from last year) via GDAL

	= Ideas by Moriz Lennert =		= Ideas by Moriz Lennert =

⚠️Wolf: /* wxGui */

2008-02-22T07:39:33Z

wxGui

← Older revision		Revision as of 07:39, 22 February 2008
Line 23:		Line 23:
	** gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)		** 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.		** The same except would create an R script.
	**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>		'''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 =		= other =

⚠️Wolf at 07:36, 22 February 2008

2008-02-22T07:36:36Z

← Older revision		Revision as of 07:36, 22 February 2008
Line 5:		Line 5:
	** Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.		** 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.		** Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.
	'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>		'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

	= Uniforming the vector modules =		= Uniforming the vector modules =
	** Vector 3D support. Make all vector modules work in 3D space.		* 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)		* 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>		**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

	= Line of sight =		= Line of sight =
Line 21:		Line 21:
	* create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]		* 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)		* 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)		** 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.		** The same except would create an R script.
	'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>		**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

	= other =		= other =
Line 29:		Line 29:
	* 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.		* 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?		** is this at all feasible?
	'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>		**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>

	* Implement new TIN algorithms from		* 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)
	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>
	'''Mentor:''' Wolf Bergenheim <wolf+grass [] bergenheim.net>

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

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

	* R integration [there was some talk on this on the list]		* 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)		* 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		* r.external (from last year) via GDAL
Line 54:		Line 54:
	* (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)		* (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)		* 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:		== More ambitious ==
	* implement an equivalent of eCognition's object-based classification (in		* implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)
	contrast to pixel-based classification)

	= Ideas by Helena Mitasova =		= 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).		* 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 =		= 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).		* 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>

⚠️Wolf at 23:45, 21 February 2008

2008-02-21T23:45:21Z

New page

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