Difference between revisions of "GRASS SoC Ideas 2013"
From GRASS-Wiki
(→Ideas) |
(→Ideas) |
||
Line 35: | Line 35: | ||
=== Vector === | === Vector === | ||
− | + | # Line intersection: implement an efficient algorithm based on literature review, focusing on the [http://en.wikipedia.org/wiki/Bentley-Ottmann_algorithm Bentley-Ottmann algorithm] and its derivates. The best or best two should be implemented. Coupled to the problem of calculating line intersections is the problem of calculating segment intersections, currently implemented in Vect_segment_intersection() and dig_find_intersection(), which could also be replaced with more efficient algorithms. | |
+ | #* Rationale: the current function Vect_line_intersection() is "home-brew" and rather slow for lines with many segments, whereas the Bentley-Ottmann algorithm can find line intersections in logarithmic time per intersection. | ||
+ | #* Requirements: at least interest in, preferably knowledge of the art of searching and sorting (search trees, priority queues, heaps). | ||
+ | #* Implementation goals: One function to search for intersections between two lines, ignoring self-intersections, and another function to test one single line for self-intersections. The API and output should be compatible with the current Vect_line_intersection() function. Optionally an alternative to Vect_segment_intersection(). | ||
+ | # ''Your suggestion here!'' | ||
+ | |||
+ | '''Willing to Mentor:''' Markus Metz | ||
=== Temporal GIS Algebra for raster and vector data === | === Temporal GIS Algebra for raster and vector data === |
Revision as of 12:44, 4 March 2013
Contents
About
This is the GRASS page for Google Summer of Code 2013. Here we will list project ideas and and other information related to the GRASS GSoC projects.
Ideas
- Project ideas of your own are also most welcome and often the best.
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.
Symbology / Cartography
- Allow display of a vector legend in the map display (equivalent to current d.legend implementation for rasters)
- Expand symbology
- HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the d.graph help page and ps.map's "eps" and "vpoints" instructions.
- Rework the complete set of thematic cartography tools such as d.vect.thematic and d.thematic.area and the related classification routines
Imagery
- Based on the work on segmentation in GSoC 2012 develop routines for object-based (or region-based) image classification. This probably entails:
- Characterizing segments. This includes producing statistics such as mean, median, variance of the segmented data within each delineated segment (customized interface to r.statistics2).
- Classifying segments based on the characteristics and (possibly) training areas
- Interface with other modules in a consistent workflow (i.cluster, r.fuzzy, etc)
- Implement hierarchical classification tools (e.g. being able to create a large class "forest" with subclasses of different types of forests). Hierarchical classification is already used internally by i.gensigset/i.smap. Hierarchical segmentation can currently be done by using the output of a previous run of i.segment as input for the next run of i.segment with increased threshold.
- Interface with the Orfeo toolbox (OTB), which is an open source, ITK-based, C++ library of (spatial) image processing library. OTB implements a very wide set of interesting features for anybody working with raster data - in particular satellite imagery: radiometric corrections, orthorectification, filtering, feature extraction, image segmentation, classification, change detection, etc.
Vector
- Line intersection: implement an efficient algorithm based on literature review, focusing on the Bentley-Ottmann algorithm and its derivates. The best or best two should be implemented. Coupled to the problem of calculating line intersections is the problem of calculating segment intersections, currently implemented in Vect_segment_intersection() and dig_find_intersection(), which could also be replaced with more efficient algorithms.
- Rationale: the current function Vect_line_intersection() is "home-brew" and rather slow for lines with many segments, whereas the Bentley-Ottmann algorithm can find line intersections in logarithmic time per intersection.
- Requirements: at least interest in, preferably knowledge of the art of searching and sorting (search trees, priority queues, heaps).
- Implementation goals: One function to search for intersections between two lines, ignoring self-intersections, and another function to test one single line for self-intersections. The API and output should be compatible with the current Vect_line_intersection() function. Optionally an alternative to Vect_segment_intersection().
- Your suggestion here!
Willing to Mentor: Markus Metz
Temporal GIS Algebra for raster and vector data
We (Soeren Gebbert and Thomas Leppelt) would like to develop a temporal GIS algebra for raster and vector data in GRASS7.
Role:
- Mentor: Soeren Gebbert
- GSoC Student: Thomas Leppelt
Implementation goals:
- Spatio-temporal vector algebra module t.vect.mapcalc
- The algebra will be based on vector map operations provided from v.overlay (and, or, xor, not), v.buffer (buff_point, buff_line, buff_area), v.patch (patch), ... , temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
- The resulting module will be able to process space time vector datasets using expressions like:
# Compute the intersection between the space time vector datasets A and B
# from maps with equal time stamps. The STVDS A is used as temporal reference.
# A new STVDS C will be created with the same time stamps as A.
t.vect.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), and(A,B))"
time |STVDS|STVDS|STVDS
stamp | A | B | C
-------------------------------------
Jan 2001 | a1 | b1 | v.overlay ain=a1 bin=b1 op=and out=c1
Feb 2001 | a2 | |
Mar 2001 | | b2 |
Apr 2001 | a3 | |
May 2001 | a4 | b3 | v.overlay ain=a4 bin=b3 op=and out=c2
Jun 2001 | | b4 |
# Nested operations are supported and temporal neighborhood computation
t.vect.mapcalc input=A,B,C tempref=A output=D \
expr="D = if(successor(B) && predecessor(C), and(A, xor(successor(B), buff_point(predecessor(C), 100)))"
# Date and time can be used in the expression
t.vect.mapcalc input=A,B timeref=A output=C \
expr="C = if(start_year() >= 2001 && start_month() > 6, and(A,B), not(A,B))"
- Spatio-temporal raster algebra module t.rast.mapcalc
- The algebra will be based on the existing r.mapcalc raster map algebra, temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
- The resulting module will be able to process space time raster datasets using expressions like:
# Compute the sum between the space time raster datasets A and B
# from maps with equal time stamps. The STRDS A is used as temporal reference.
# A new STRDS C will be created with the same time stamps as A.
t.rast.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), A + B)"
# Spatio-temporal neighborhood computation. STRDS C will have the same time stamps as A.
t.rast.mapcalc input=B timeref=A output=C \
expr="C = if(successor(B) && predecessor(B), (successor(B)[0,0] + B[0,0] + predecessor(B)[0,0])/3.0, B[0,0])"
- The GRASS GIS temporal framework will be utilized and the pygrass module interface
- PLY will be used for lexical analysis and parser generation
- Temporal algebra will be equivalent for booth modules with about 60 internal variables and functions