[GRASS-dev] [GRASS GIS] #2036: Failed watershed analysis on Grass

[GRASS GIS]

#2036: Failed watershed analysis on Grass
--------------------------+-------------------------------------------------
  Reporter:  mehmeto      |       Owner:  grass-dev@…              
      Type:  defect       |      Status:  closed                   
  Priority:  normal       |   Milestone:  6.4.4                    
 Component:  Raster       |     Version:  6.4.2                    
Resolution:  fixed        |    Keywords:  LFS, r.watershed         
  Platform:  MSWindows 7  |         Cpu:  x86-64                   
--------------------------+-------------------------------------------------

Comment(by hamish):

 Replying to [comment:16 mmetz]:
 > Most GRASS 7 modules are at least as robust as in GRASS 6, and
 r.watershed
 > in GRASS 7 is suitable for production work.

 Although I'd generally caution anyone using any new/development code for
 production work that there are no guarantees, and the usual "bleeding
 edge" situation applies.
 The choice is between old, well tested, and trusted ''versus'' new &
 improved (faster, better, stronger) but lightly tested with a short track
 record. The choice is yours..

 > In GRASS 6.4.2, r.watershed is IMHO not suitable for production work.

 How about if you use the "-f" MDF flag there? Or do you mean more than
 that?
 (I take it you mean a methodological improvement, not bug fixes)

 > By default, Windows, also a 64 bit Windows, does not have LFS when
 > using the standard API, you need to use the LFS API explicitly.

 But AFAIU it can be explicitly enabled for libgis, so the programmer only
 needs to worry about it if the module uses ftell() and fseek() type
 operations. (and many of the modules already do)

 Is there a reason that --enable-largefile is not included in
 relbr_6_4/mswindows/osgeo4w/package.sh's ./configure?


 mehmeto wrote:
 > > So, I undertand that current stable version of Grass for Windows is
 not
 > > a convenient program to do such an analysis on a large map.

 use the r.watershed "-m" flag with GRASS 6, then it might be ok. (just
 take a bit longer)

 But getting back to the original bug report, if I understand correctly
 this happened with the North Carolina sample dataset's 'elevation' raster
 map due to a missing step in the quick-start tutorial: right click on the
 map name to set the computation region bounds and resolution to match the
 map before running a processing module. That map's region settings is much
 smaller than the 7000 rows,cols reported, so it should run ok without any
 memory issues in 32bit WinGrass.


 regards,
 Hamish

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