[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 mmetz):

 Replying to [comment:17 hamish]:
 > Replying to [comment:16 mmetz]:
 >
 > > 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)

 I mean bug fixes. Some bugs have been fixed only in 6.4.3 and later. Also,
 r.watershed in G7 uses less memory and is faster.
 >
 > > 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)

 It's not so easy for Windows. You need to use the LFS API explicitely,
 i.e. off64_t, fseeko64(), ftello64, lseek64(), _stati64, etc.
 >
 > Is there a reason that --enable-largefile is not included in
 relbr_6_4/mswindows/osgeo4w/package.sh's ./configure?

 Yes, because --enable-largefile has no effect for wingrass 6.x. LFS on
 Windows is only available for G7, not for G6, independent of any
 configuration options.
 >
 >
 > 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)

 In this case, it is not a matter of processing time, but if the module
 finishes at al. For trunk, the -m flag could become the default, in order
 to avoid tickets like this.

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