Talk:GRASS SoC Ideas 2008: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (7 intermediate revisions by 4 users not shown) | |||
| 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 | '''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 = | ||
* 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 | **'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net> | ||
= 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]] | ||
= wxGui = | = wxGui = | ||
| Line 21: | Line 24: | ||
* 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) | |||
** The same except would create an R script. | |||
'''Mentor:''' Wolf Bergenheim <wolf+grass | '''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. | * 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 | **'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net> | ||
* Implement new TIN algorithms from | = Vector = | ||
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) | ||
'''Mentor:''' Wolf Bergenheim <wolf+grass | **'''Willing to 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 | **'''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 | **'''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 | **'''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] | ||
* 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> | |||
= 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) | * (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. 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> | |||
Latest revision as of 07:25, 12 March 2008
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): 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>