[GRASS-dev] [GRASS GIS] #2036: Failed watershed analysis on Grass
GRASS GIS
trac at osgeo.org
Fri Jul 19 22:15:07 PDT 2013
#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>
More information about the grass-dev
mailing list