[GRASS-dev] [GRASS GIS] #2296: r.stream.* - unify some functions (avoid code duplication)

[GRASS GIS]

#2296: r.stream.* - unify some functions (avoid code duplication)
-------------------------+--------------------------------------------------
 Reporter:  hellik       |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  major        |   Milestone:  7.0.0                    
Component:  Raster       |     Version:  svn-trunk                
 Keywords:  r.stream.*   |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by hellik):

 Replying to [comment:1 glynn]:
 > Replying to [ticket:2296 hellik]:
 >
 > > to avoid code duplication, some functions should be unified over these
 modules in a lib(?)
 >
 > While we're at it, maybe we should look into unifying all of the
 different "segment" libraries.
 >
 > They all do essentially the same thing: provide a 2-dimensional array
 which may be too large to fit into RAM (or, more accurately, into the
 process' address space; if RAM was the issue, mmap() etc would suffice),
 and which can be accessed (more or less) randomly.
 >
 > Apart from the "official" segment library (lib/segment), r.proj has its
 own, r.stream.* each have their own, r.grow.distance has something simpler
 (the temporary file is read row-by-row but in reverse).

 {{{
 http://trac.osgeo.org/grass/browser/grass/trunk/lib/segment
 http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.grow.distance
 http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.proj
 http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.extract
 }}}

 unifying all of the different "segment" libraries may be a good choice.

 worth to open a new ticket?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2296#comment:2>
GRASS GIS <http://grass.osgeo.org>