Hi,
I recently tried to interpolate some data using v.surf.rst but ran into
trouble. I'm pretty sure I've interpolated since my last fresh install, so
maybe it is an update that's causing the trouble. I'm using Ubuntu 10.04
64bit.
I have GRASS70 compiled from source and GRASS6.4 from the package manager.
When I try to run v.surf.rst from the command line, it starts and maxes the
cpu but never gets past 0% in both GRASS versions. When I run it from tcltk
gui it does the same thing. When I run it from python gui I sometimes get:
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 7354 error_code 2 request_code 18 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Does this sound familiar to anyone?
Thanks,
Eric
On Thu, Sep 2, 2010 at 3:06 PM, Eric Hardin <hardinej@gmail.com> wrote:
Hi,
I recently tried to interpolate some data using v.surf.rst but ran into
trouble. I'm pretty sure I've interpolated since my last fresh install, so
maybe it is an update that's causing the trouble. I'm using Ubuntu 10.04
64bit.
I have GRASS70 compiled from source and GRASS6.4 from the package manager.
When I try to run v.surf.rst from the command line, it starts and maxes the
cpu but never gets past 0% in both GRASS versions. When I run it from tcltk
gui it does the same thing.
Please post the output of
g.region -p
Perhaps too many rows/cols?
Markus
When I run it from python gui I sometimes get:
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 7354 error_code 2 request_code 18 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Does this sound familiar to anyone?
Thanks,
Eric
That was exactly the problem. Sorry for the bother.
I was trying to import data in units of feet into a meters location. So, I
guess there were about 3x as many rows and cols as should have had. Oh, it's
so embarrassing to have problems with region, units, and masks.
Thanks for answering though.
Eric