[GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory

GRASS GIS trac at osgeo.org
Mon Jun 20 01:08:20 PDT 2016


#2045: r.to.vect: use less memory
--------------------------+-------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.0.5
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  r.to.vect
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mmetz):

 Replying to [comment:10 mlennert]:
 > A colleague who was trying to vectorize +/- 13 mio segments (output of
 i.segment) just ran into the same problem of memory saturation during the
 topology creation phase.

 As a workaround, you could use `r.to.vect -b` and then build topology
 separately with v.build.

 >
 > The tiling approach is interesting, we will look into that,

 See also the GRASS addon r.to.vect.tiled [0]

 > but it would be nice if a possibility was found to make the whole
 r.to.vect process more efficient. I have no idea, how, though...

 The module already writes out a boundary as soon as it has been completed
 and attempts to free memory used to track this boundary. I suspect more
 serious memory leaks in r.to.vect during the extraction phase. Even though
 the module tries to free all memory used during extraction, it seems that
 some allocated memory is no longer accessible. I have an idea where to
 look for the memory leak
 ([https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.to.vect/areas.c#L157
 update_list()]), but it will not be a quick fix.

 [0] https://grass.osgeo.org/grass70/manuals/addons/r.to.vect.tiled.html

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2045#comment:11>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list