I have 9 raster elevation files that cover the entire state. When displayed
simultaneously there are obvious mis-matches along the edges apparently
because of different hight ranges. Yesterday I attempted to create a single
DEM map for the entire state using r.patch.
These are the steps I fol
On Fri, 15 Jan 2010, Rich Shepard wrote:
I need ideas on how to find the source of the problem. What might cause
such an error?
Does anyone know why r.patch and/or r.series would generate an error about
not being able to write a row when maps are concatenated? It seems to me
that if the dat
Rich Shepard wrote:
> > I need ideas on how to find the source of the problem. What might cause
> > such an error?
>
>Does anyone know why r.patch and/or r.series would generate an error about
> not being able to write a row when maps are concatenated? It seems to me
> that if the data are
On Thu, 21 Jan 2010, Glynn Clements wrote:
The error "map [%s] - unable to write row %d" doesn't originate in a
module, it originates in the library, and invariably indicates that
write() failed.
[If you're getting a different error, please post the *exact* error
message, not a paraphrase.]
H
Rich Shepard wrote:
> GRASS 6.5.svn (Oregon):/usr4/grassbase > r.patch in=$MAPS out=demOR --o
> WARNING: map [demOR] - unable to write row 24578 (No such file or
> directory)
"No such file or directory" is ENOENT, which isn't among the errors
which write() can return. That suggests tha
On Fri, 22 Jan 2010, Glynn Clements wrote:
Can you revert the previous patch with:
patch -R -p0 < write_errno.patch
then apply the attached patch with:
patch -R -p0 < write_errors.patch
and re-compile.
That should cause it to print more than one error.
GRASS 6.5.svn (Oregon):/
Rich Shepard wrote:
> > Can you revert the previous patch with:
> > patch -R -p0 < write_errno.patch
> > then apply the attached patch with:
> > patch -R -p0 < write_errors.patch
> > and re-compile.
> > That should cause it to print more than one error.
>
>
> GRASS 6.5.svn (Oregon):/usr
On Sat, 23 Jan 2010, Glynn Clements wrote:
Actually, I want to know why the 2GiB limit is there.
Glynn,
Me, too!
1. Can you confirm that include/Make/Platform.make contains:
#Large File Support (LFS)
USE_LARGEFILES = 1
Yes, those two lines are present.
2. Can y
Rich Shepard wrote:
> > 2. Can you re-compile lib/gis and check that the compilation commands
> > include the flag -D_FILE_OFFSET_BITS=64.
>
>lib/gis/Makefile contains:
>
> #compile if LFS Large File Support present:
> ifneq ($(USE_LARGEFILES),)
> EXTRA_CFLAGS = -D_FILE_OFFSET_BITS
On Sun, 24 Jan 2010, Glynn Clements wrote:
Right. But if you do e.g.:
touch lib/gis/opencell.c
make -C lib/gis
does the -D_FILE_OFFSET_BITS=64 switch appear in the output?
Glynn,
It appears so:
gcc -I/usr4/grass65/dist.i686-pc-linux-gnu/include -I/usr/include/ -g -O2
-I/u
On Sun, 24 Jan 2010, Glynn Clements wrote:
One possibility is that GRASS was initially built without LFS, then
configure was re-run with --enable-largefile and GRASS was built without
first performing "make clean". This would result in most of the files not
be re-compiled.
Glynn,
This must
On Fri, 15 Jan 2010, Rich Shepard wrote:
There was a warning about inability to write line 24nnn (I forget the
exact line number), and when it was finished and I tried to display the
whole new map, only the top portion (I'd estimate the top half) was present.
I need ideas on how to find the
Rich Shepard wrote:
> > There was a warning about inability to write line 24nnn (I forget the
> > exact line number), and when it was finished and I tried to display the
> > whole new map, only the top portion (I'd estimate the top half) was present.
>
>I need ideas on how to find the sourc
On Fri, 15 Jan 2010, Glynn Clements wrote:
The most likely reasons are:
1. Your version of GRASS was built without LFS (large file support),
and the cell/fcell file reached the 2GiB limit.
Glynn,
Nope. LFS was enabled.
2. The disk is full or you exceeded your quota.
Nope. There are 1
14 matches
Mail list logo
