On 11/02/2015 14:55, Pierric de Laborie
wrote:
Dear Pietro,
I ran the same command with the highest level of verbose.
Unfortunately it didn't give much more information when
blocking at the problematic step.
I wonder if there is any idea/intention to built in kind of a check
mechanism for modules applicable to raster data. This, and the Εxtent
concept as well, are most frequent problems/inattentions.
Nikos
On 12.02.2015 10:33, Pierric de Laborie wrote:
Thanks for your input. This was probably
On Thu, Feb 12, 2015 at 3:33 AM, Pierric de Laborie
pierric.delabo...@gmail.com wrote:
Grass defaulted the region to the raster with the highest resolution.
GRASS is not doing anything like that. The computation region is always set
by the user (typically using g.region) except for the case
Thanks for your input. This was probably the reason why. Grass defaulted
the region to the raster with the highest resolution.
2015-02-12 9:23 GMT+01:00 Micha Silver mi...@arava.co.il:
On 11/02/2015 14:55, Pierric de Laborie wrote:
Dear Pietro,
I ran the same command with the highest
Dear Pierric,
On Wed, Feb 11, 2015 at 10:02 AM, Pierric de Laborie
pierric.delabo...@gmail.com wrote:
I don't understand why Grass seems to get stuck on the following Python
command :
r.composite(red=B4,green=B3,blue=B2,output=mycomposite,quiet=QUIET,overwrite=OVR)
Have you tried to run the
Hello,
I am using Grass 7.0 through Python and Pygrass (from outside Grass without
starting it) on Linux (Debian GNU/Linux 7.6 (wheezy)) .
I don't understand why Grass seems to get stuck on the following Python
command :
I have just tried to start the same command from the GRASS shell (same
machine and same GRASS database and location) and it gets stuck also.
GRASS 7.0.0svn (222):~/Grass_test r.composite red=B5@PERMANENT
green=B4@PERMANENT blue=B3@PERMANENT output=mycompo
Creating color table for output raster
