Details Ticket 3011


Comment | Reply | Take | Open


Serial Number 3011
Subject d.mon CELL doesn't work
Area grass6
Queue grass
Requestors harterc1@comcast.net,werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Fri Jun 23 21:47:37 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Sep 27 01:24:52 2006 (2 yr ago)
Created Fri Feb 18 00:07:17 2005 (4 yr ago)

Transaction History Ticket 3011


Fri, Feb 18 2005 00:07:17    Request created by guest  
Subject: d.mon CELL doesn't work

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot_2005_01_22

GRASS 6.0.cvs:~ > d.mon CELL
Could not execute monitor: No such file or directory
No socket to connect to for monitor <CELL>.
Problem selecting CELL. Will try once more
No socket to connect to for monitor <CELL>.

GRASS 6.0.cvs:~ > d.mon stop=CELL
Error - No such monitor as 'CELL'

But listed anyway as available:

GRASS 6.0.cvs:~ > d.mon -L
name            description                    status
----            -----------                    ------
x0              X-windows graphics display     running (selected)
x1              X-windows graphics display     not running
x2              X-windows graphics display     not running
x3              X-windows graphics display     not running
x4              X-windows graphics display     not running
x5              X-windows graphics display     not running
x6              X-windows graphics display     not running
CELL            Create GRASS Raster File       not running
PNG             Create PNG Map                 not running

Maciek
Mon, Mar 7 2005 19:40:20    Request created by guest (as #3076)  
Subject: CELL dirver fails

Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot_2005_03_05

child process exited abnormally
    while executing
"exec -- d.mon start=CELL >@ stdout 2>@ stderr"
    ("eval" body line 1)
    invoked from within
"eval exec -- $cmd $args >@ stdout 2>@ stderr"
    (procedure "run" line 2)
    invoked from within
"run d.mon start=CELL"
    invoked from within
".#menubar.#menubar#menu2.#menubar#menu2#menu4 invoke active"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke active]"
    (procedure "tkMenuInvoke" line 47)
    invoked from within
"tkMenuInvoke .#menubar.#menubar#menu2.#menubar#menu2#menu4 1
"Welcome to GRASS 6.0.cvs (2005) 
GRASS homepage:                          http://grass.itc.it/
This version running thru:               Bash Shell (/bin/bash)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
If required, restart the graphical user interface with: d.m &
When ready to quit enter:                exit
GRASS 6.0.cvs (lafay_gdal):/ext2e/data/GRASSDATA > Could not execute monitor:
No such file or directory
No socket to connect to for monitor <CELL>.
Problem selecting CELL. Will try once more
No socket to connect to for monitor <CELL>.



Tue, Mar 8 2005 17:47:15    Mail sent by neteler@itc.it (as #3076)  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 8 Mar 2005 17:47:12 +0100
From Markus Neteler <neteler@itc.it>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3076] (grass) CELL dirver fails
Message-ID <20050308164711.GF10379@thuille.itc.it>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20050307184020.D5853100160@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20050307184020.D5853100160@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Mon, Mar 07, 2005 at 07:40:20PM +0100, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3076
> -------------------------------------------------------------------------
> 
> Subject: CELL dirver fails
> 
> Platform: GNU/Linux/i386
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: grass-6.0.cvs_src_snapshot_2005_03_05
> 
> child process exited abnormally
>     while executing
> "exec -- d.mon start=CELL >@ stdout 2>@ stderr"
...

> GRASS 6.0.cvs (lafay_gdal):/ext2e/data/GRASSDATA > Could not execute monitor:
No such file or directory
> No socket to connect to for monitor <CELL>.
> Problem selecting CELL. Will try once more
> No socket to connect to for monitor <CELL>.

The CELL driver was not ported (yet?) to GRASS 6.
Please use the PNG driver which is even more powerful.

Markus


Tue, Mar 8 2005 17:51:26    Mail sent by michael.barton@asu.edu (as #3076)  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 08 Mar 2005 09:49:52 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] [bug #3076] (grass) CELL dirver fails
In-reply-to <20050307184020.D5853100160@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <BE5325C0.10645%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.1.0.040913
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
The CELL driver has been non-functional since the switch to 5.7 (now 6). I
don't know why it still shows up as existing when you list available
monitors, but this should probably be disabled--unless there are plans to
revive the CELL driver.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Request Tracker <grass-bugs@intevation.de>
> Reply-To: Request Tracker <grass-bugs@intevation.de>
> Date: Mon,  7 Mar 2005 19:40:20 +0100 (CET)
> To: <grass5@grass.itc.it>
> Subject: [GRASS5] [bug #3076] (grass) CELL dirver fails
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3076
> -------------------------------------------------------------------------
> 
> Subject: CELL dirver fails
> 
> Platform: GNU/Linux/i386
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: grass-6.0.cvs_src_snapshot_2005_03_05
> 
> child process exited abnormally
>     while executing
> "exec -- d.mon start=CELL >@ stdout 2>@ stderr"
>     ("eval" body line 1)
>     invoked from within
> "eval exec -- $cmd $args >@ stdout 2>@ stderr"
>     (procedure "run" line 2)
>     invoked from within
> "run d.mon start=CELL"
>     invoked from within
> ".#menubar.#menubar#menu2.#menubar#menu2#menu4 invoke active"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel #0 [list $w invoke active]"
>     (procedure "tkMenuInvoke" line 47)
>     invoked from within
> "tkMenuInvoke .#menubar.#menubar#menu2.#menubar#menu2#menu4 1
> "Welcome to GRASS 6.0.cvs (2005)
> GRASS homepage:                          http://grass.itc.it/
> This version running thru:               Bash Shell (/bin/bash)
> Help is available with the command:      g.manual -i
> See the licence terms with:              g.version -c
> If required, restart the graphical user interface with: d.m &
> When ready to quit enter:                exit
> GRASS 6.0.cvs (lafay_gdal):/ext2e/data/GRASSDATA > Could not execute monitor:
> No such file or directory
> No socket to connect to for monitor <CELL>.
> Problem selecting CELL. Will try once more
> No socket to connect to for monitor <CELL>.
> 
> 
> 
> 
> 
> -------------------------------------------- Managed by Request Tracker
> 


Wed, Mar 9 2005 02:49:57    Mail sent by donharter@comcast.net (as #3076)  
Return-Path <donharter@comcast.net>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <422E55A4.6090902@comcast.net>
Date Tue, 08 Mar 2005 19:47:16 -0600
From Don Harter <donharter@comcast.net>
User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language en-us, en
MIME-Version 1.0
To Michael Barton via RT <grass-bugs@intevation.de>
Cc grass-bugs@intevation.de
Subject Re: [bug #3076] (grass) CELL dirver fails
References <20050308165127.00AE41005B1@lists.intevation.de>
In-Reply-To <20050308165127.00AE41005B1@lists.intevation.de>
X-Enigmail-Version 0.89.6.0
X-Enigmail-Supports pgp-inline, pgp-mime
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Michael Barton via RT wrote:

>The CELL driver has been non-functional since the switch to 5.7 (now 6). I
>don't know why it still shows up as existing when you list available
>monitors, but this should probably be disabled--unless there are plans to
>revive the CELL driver.
>
>Michael
>______________________________
>Michael Barton, Professor of Anthropology
>School of Human Evolution and Social Change
>Arizona State University
>Tempe, AZ  85287-2402
>USA
>
>voice: 480-965-6262; fax: 480-965-7671
>www: http://www.public.asu.edu/~cmbarton
>
>
>  
>
>>From: Request Tracker <grass-bugs@intevation.de>
>>Reply-To: Request Tracker <grass-bugs@intevation.de>
>>Date: Mon,  7 Mar 2005 19:40:20 +0100 (CET)
>>To: <grass5@grass.itc.it>
>>Subject: [GRASS5] [bug #3076] (grass) CELL dirver fails
>>
>>this bug's URL: http://intevation.de/rt/webrt?serial_num=3076
>>-------------------------------------------------------------------------
>>
>>Subject: CELL dirver fails
>>
>>Platform: GNU/Linux/i386
>>grass obtained from: Trento Italy site
>>grass binary for platform: Compiled from Sources
>>GRASS Version: grass-6.0.cvs_src_snapshot_2005_03_05
>>
>>child process exited abnormally
>>    while executing
>>"exec -- d.mon start=CELL >@ stdout 2>@ stderr"
>>    ("eval" body line 1)
>>    invoked from within
>>"eval exec -- $cmd $args >@ stdout 2>@ stderr"
>>    (procedure "run" line 2)
>>    invoked from within
>>"run d.mon start=CELL"
>>    invoked from within
>>".#menubar.#menubar#menu2.#menubar#menu2#menu4 invoke active"
>>    ("uplevel" body line 1)
>>    invoked from within
>>"uplevel #0 [list $w invoke active]"
>>    (procedure "tkMenuInvoke" line 47)
>>    invoked from within
>>"tkMenuInvoke .#menubar.#menubar#menu2.#menubar#menu2#menu4 1
>>"Welcome to GRASS 6.0.cvs (2005)
>>GRASS homepage:                          http://grass.itc.it/
>>This version running thru:               Bash Shell (/bin/bash)
>>Help is available with the command:      g.manual -i
>>See the licence terms with:              g.version -c
>>If required, restart the graphical user interface with: d.m &
>>When ready to quit enter:                exit
>>GRASS 6.0.cvs (lafay_gdal):/ext2e/data/GRASSDATA > Could not execute monitor:
>>No such file or directory
>>No socket to connect to for monitor <CELL>.
>>Problem selecting CELL. Will try once more
>>No socket to connect to for monitor <CELL>.
>>
>>
>>
>>
>>
>>-------------------------------------------- Managed by Request Tracker
>>
>>    
>>
>
>
>--- Headers Follow ---
>
>>From Michael.Barton@asu.edu  Tue Mar  8 17:51:26 2005
>Return-Path: <Michael.Barton@asu.edu>
>Delivered-To: grass-bugs@lists.intevation.de
>Received: from mail.intevation.de (aktaia [212.95.126.10])
>	by lists.intevation.de (Postfix) with ESMTP id C29E41005B0
>	for <grass-bugs@lists.intevation.de>; Tue,  8 Mar 2005 17:51:26 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by mail.intevation.de (Postfix) with ESMTP id 886E936CE3
>	for <grass-bugs@lists.intevation.de>; Tue,  8 Mar 2005 17:51:26 +0100 (CET)
>Received: from post5.inre.asu.edu (post5.inre.asu.edu [129.219.110.120])
>	by mail.intevation.de (Postfix) with ESMTP id F2DF536CDD
>	for <grass-bugs@intevation.de>; Tue,  8 Mar 2005 17:51:23 +0100 (CET)
>Received: from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769)
> id <0ID100601LF466@asu.edu> for grass-bugs@intevation.de; Tue,
> 08 Mar 2005 09:49:52 -0700 (MST)
>Received: from ex7.asurite.ad.asu.edu (ex7.asurite.ad.asu.edu [129.219.10.210])
> by asu.edu (PMDF V6.1-1X6 #30769) with ESMTP id <0ID10056JLF4XH@asu.edu>; Tue,
> 08 Mar 2005 09:49:52 -0700 (MST)
>Received: exchange.asu.edu 129.219.10.210 from 129.219.10.231 129.219.10.231
> via HTTP with MS-WebStorage 6.0.6249
>Received: 129.219.10.231 129.219.10.231 from   via HTTP with MS-WebStorage
> 6.0.6249
>Date: Tue, 08 Mar 2005 09:49:52 -0700
>From: Michael Barton <michael.barton@asu.edu>
>Subject: Re: [GRASS5] [bug #3076] (grass) CELL dirver fails
>In-reply-to: <20050307184020.D5853100160@lists.intevation.de>
>To: Paolo Cavallini via RT <grass-bugs@intevation.de>,
>	grass5@grass.itc.it
>Message-id: <BE5325C0.10645%michael.barton@asu.edu>
>MIME-version: 1.0
>Content-type: text/plain; charset=US-ASCII
>Content-transfer-encoding: 7bit
>User-Agent: Microsoft-Entourage/11.1.0.040913
>X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
>X-Spam-Level: 
>
>-------------------------------------------- Managed by Request Tracker
>
>  
>
I was using the cell driver so that I could export the current 
display.   I wanted to take DRG map, plot some points and labels on it 
and then export it back to DRG tiff file.  This seemed the only way to 
do that.  So unless there is another way, I would hope that the cell 
driver is ported.


Wed, Mar 9 2005 06:09:11    Mail sent by hamish_nospam@yahoo.com (as #3076)  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 9 Mar 2005 18:08:47 +1300
From Hamish <hamish_nospam@yahoo.com>
To grass5@grass.itc.it
Cc grass-bugs@intevation.de
Subject Re: [GRASS5] [bug #3076] (grass) CELL dirver fails
Message-Id <20050309180847.6d3fa449.hamish_nospam@yahoo.com>
In-Reply-To <BE5325C0.10645%michael.barton@asu.edu>
References <20050307184020.D5853100160@lists.intevation.de> <BE5325C0.10645%michael.barton@asu.edu>
X-Mailer Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3076
> ---------------------------------------------------------------------
..
Michael:
> The CELL driver has been non-functional since the switch to 5.7 (now
> 6). I don't know why it still shows up as existing when you list
> available monitors, but this should probably be disabled--unless there
> are plans to revive the CELL driver.

Markus:
> The CELL driver was not ported (yet?) to GRASS 6.
> Please use the PNG driver which is even more powerful.


Is there any point/advantage to having a CELL driver anymore?
What could it be used for that can't be done via another path?

http://grass.ibiblio.org/gdp/html_grass5/html/celldriver.html

Echoing Michael, if no reason to keep it, time for formal retirement?



Hamish


Mon, Mar 14 2005 00:55:05    Mail sent by glynn@gclements.plus.com (as #3076)  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16948.53966.304143.686688@gargle.gargle.HOWL>
Date Sun, 13 Mar 2005 23:54:54 +0000
To Hamish <hamish_nospam@yahoo.com>
Cc grass5@grass.itc.it, grass-bugs@intevation.de
Subject Re: [GRASS5] [bug #3076] (grass) CELL dirver fails
In-Reply-To <20050309180847.6d3fa449.hamish_nospam@yahoo.com>
References <20050307184020.D5853100160@lists.intevation.de> <BE5325C0.10645%michael.barton@asu.edu> <20050309180847.6d3fa449.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Hamish wrote:

> > The CELL driver has been non-functional since the switch to 5.7 (now
> > 6). I don't know why it still shows up as existing when you list
> > available monitors, but this should probably be disabled--unless there
> > are plans to revive the CELL driver.
> 
> Markus:
> > The CELL driver was not ported (yet?) to GRASS 6.
> > Please use the PNG driver which is even more powerful.
> 
> Is there any point/advantage to having a CELL driver anymore?
> What could it be used for that can't be done via another path?

Given that both the CELL and PNG drivers behave in a near-identical
manner, i.e. store values in a 2D "array" then convert the array to an
external representation upon either termination or R_close_driver(),
there should probably be some re-factoring in that area.

IOW, either:

a) merge the CELL and PNG drivers so that the CELL functionality is
essentially just another output "target" (e.g. if GRASS_PNGFILE
doesn't end in ".png" or ".ppm", it's treated as a map name), or

b) move the bulk of the PNG driver into a library; either the existing
driverlib or a new library specifically for drivers which behave like
the CELL and PNG drivers.

-- 
Glynn Clements <glynn@gclements.plus.com>


Sat, Jul 23 2005 15:03:16    Area changed to grass6.1 by msieczka  
Sat, Jul 23 2005 15:18:00    Mail sent by msieczka  
Still present in 6.1.

CELL driver was never ported to 6.1. And there was a discussion about getting
rid of CELL driver for good.

What are your conlusions? Is it really a good idea not to support this
solution anymore? As I understand (never used it), CELL driver lets me dump
the screen content directly into Grass raster, together with the color table,
right?

If so, d.out.png + r.in.gdal (+r.composite in case of over 8 bit image dumps)
is less comfortable and requires an intermediate file. Besides, it will be
hard to obtain an *exact* copy of the over 8-bit colour display with
r.composite, no?

Maciek
Sun, Jul 24 2005 00:16:43    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17122.55943.837700.641786@cerise.gclements.plus.com>
Date Sun, 24 Jul 2005 01:02:15 +0100
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc werchowyna@pf.pl, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
In-Reply-To <20050723131800.2305A1005A9@lists.intevation.de>
References <20050723131800.2305A1005A9@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek Sieczka via RT wrote:

> CELL driver was never ported to 6.1. And there was a discussion about getting
> rid of CELL driver for good.
> 
> What are your conlusions? Is it really a good idea not to support this
> solution anymore? As I understand (never used it), CELL driver lets me dump
> the screen content directly into Grass raster, together with the color table,
> right?
> 
> If so, d.out.png + r.in.gdal (+r.composite in case of over 8 bit image dumps)
> is less comfortable and requires an intermediate file. Besides, it will be
> hard to obtain an *exact* copy of the over 8-bit colour display with
> r.composite, no?

The preferred solution is the PNG driver, plus r.in.gdal[1] if you
want to import the image as a map (I have no idea why you would; it's
unlikely to be georeferenced correctly).

Note that the PNG driver can create 8-, 24- or 32-bpp PNG files, plus
24-bpp PPM files with an optional PGM mask file.

[1] Or, preferably, r.in.png once I add it to 6.1; I've only just
realised it was missing.

-- 
Glynn Clements <glynn@gclements.plus.com>


Sun, Jul 24 2005 20:49:23    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <021601c59080$52b0a890$8be41d3e@eustahiush>
From "Maciek Sieczka" <werchowyna@epf.pl>
To "Glynn Clements" <glynn@gclements.plus.com>, <grass-bugs@intevation.de>
Cc <werchowyna@pf.pl>, <grass5@grass.itc.it>
References <20050723131800.2305A1005A9@lists.intevation.de> <17122.55943.837700.641786@cerise.gclements.plus.com>
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
Date Sun, 24 Jul 2005 20:47:38 +0200
MIME-Version 1.0
Content-Type text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original
Content-Transfer-Encoding 7bit
X-Priority 3
X-MSMail-Priority Normal
X-Mailer Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus avast! (VPS 0528-4, 2005-07-14), Outbound message
X-Antivirus-Status Clean
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
From: "Glynn Clements" <glynn@gclements.plus.com>

> Maciek Sieczka via RT wrote:
>
>> CELL driver was never ported to 6.1. And there was a discussion about 
>> getting
>> rid of CELL driver for good.
>>
>> What are your conlusions? Is it really a good idea not to support this
>> solution anymore? As I understand (never used it), CELL driver lets me 
>> dump
>> the screen content directly into Grass raster, together with the color 
>> table,
>> right?
>>
>> If so, d.out.png + r.in.gdal (+r.composite in case of over 8 bit image 
>> dumps)
>> is less comfortable and requires an intermediate file. Besides, it will 
>> be
>> hard to obtain an *exact* copy of the over 8-bit colour display with
>> r.composite, no?
>
> The preferred solution is the PNG driver, plus r.in.gdal[1] if you
> want to import the image as a map

> (I have no idea why you would

Because we are talking here about substituting the CELL driver 
functionality. And as I understand it, CELL driver is for obtaining a Grass 
layer out of the monitor content (not a particular layer, like r.out.gdal, 
or a fragment of layer currently displayed, like r.out.tiff -t) with a 
colortable stored.

> unlikely to be georeferenced correctly).

Sure.

So here all arguments for having CELL driver to Grass61:
1. d.out.png + r.in.gdal requires an intermediate file to duplicate the CELL
driver functionality
2. r.region is required to georeference the PNG image dump back after 
r.in.gdal
3. if the image dump was over 8 bit, r.composite is required to merge the 3 
layers output by r.in.gdal; moreover, using r.composite, it is unlikely to 
obtain an exact copy of the original PNG image dump
4. alltogether, even if possible to overcome all these problem, CELL driver 
seems much easier in use - one operation instead of 3 or 4.

My question is if, in the light of above, CELL driver should be ported to 
Grass61 or not and if it is likely to be done. I'm not insisting because I'm
not actually interested in having this functionality. I'm asking in order to
sort this issue out and so we had an appropriate information in the 
bugtracker entry for this problem.

> Note that the PNG driver can create 8-, 24- or 32-bpp PNG files, plus
> 24-bpp PPM files with an optional PGM mask file.
>
> [1] Or, preferably, r.in.png once I add it to 6.1; I've only just
> realised it was missing.

Why do we need r.in.png if r.in.gdal provides this functionality?

Maciek 


Sun, Jul 24 2005 21:54:22    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Sun, 24 Jul 2005 20:54:13 +0100 (BST)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
To Maciek Sieczka <werchowyna@epf.pl>
Cc Glynn Clements <glynn@gclements.plus.com>, grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
In-Reply-To <021601c59080$52b0a890$8be41d3e@eustahiush>
Message-ID <Pine.LNX.4.60.0507242046070.16941@agrippa.ukshells.co.uk>
References <20050723131800.2305A1005A9@lists.intevation.de> <17122.55943.837700.641786@cerise.gclements.plus.com> <021601c59080$52b0a890$8be41d3e@eustahiush>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Do-Not-Run Yes
X-SA-Exim-Connect-IP 217.10.143.90
X-SA-Exim-Mail-From paul-grass@stjohnspoint.co.uk
X-SA-Exim-Scanned No (on customer-relay-1.mail.uksolutions.net); SAEximRunCond expanded to false
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Sun, 24 Jul 2005, Maciek Sieczka wrote:

> Because we are talking here about substituting the CELL driver 
> functionality. And as I understand it, CELL driver is for obtaining a 
> Grass layer out of the monitor content (not a particular layer, like 
> r.out.gdal, or a fragment of layer currently displayed, like r.out.tiff 
> -t) with a colortable stored.

The only thing I can think that would be useful for was before there were 
direct monitor output methods like the PNG driver, you could write the 
monitor to a GRASS raster layer and then use r.out.tiff or whatever to get 
it into an output file.

>
>> unlikely to be georeferenced correctly).
>
> Sure.
>
> So here all arguments for having CELL driver to Grass61:
> 1. d.out.png + r.in.gdal requires an intermediate file to duplicate the 
> CELL driver functionality

But I can't think of a reason why you would want a monitor image as a 
GRASS raster; rather I would put it that it is the CELL driver that 
requires two images to get to an output graphics file.

> 2. r.region is required to georeference the PNG image dump back after 
> r.in.gdal

LIkewise for the CELL driver directly; the output image is not 
georeferenced as Glynn said.

> 3. if the image dump was over 8 bit, r.composite is required to merge the 
> 3 layers output by r.in.gdal; moreover, using r.composite, it is unlikely 
> to obtain an exact copy of the original PNG image dump

Make the image dump in 8-bit colour then.

> 4. alltogether, even if possible to overcome all these problem, CELL 
> driver seems much easier in use - one operation instead of 3 or 4.

It makes it easy to convert a monitor image into a GRASS raster, but what 
use is it once you've got it there? I feel it is an historical 
anachronism.

[...]
>> [1] Or, preferably, r.in.png once I add it to 6.1; I've only just
>> realised it was missing.
>
> Why do we need r.in.png if r.in.gdal provides this functionality?

I suppose it is simpler and doesn't rely in having GDAL working properly; 
Glynn may be able to describe technical advantages it has over GDAL 
specifically for the PNG format?

Just thought I'd join in, because I actually used the CELL driver for 
something years ago and so understand how useless it is :)

Paul


Tue, Jul 26 2005 08:48:01    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17125.62781.832524.674125@cerise.gclements.plus.com>
Date Tue, 26 Jul 2005 09:33:01 +0100
To "Maciek Sieczka" <werchowyna@epf.pl>
Cc <grass-bugs@intevation.de>, <werchowyna@pf.pl>, <grass5@grass.itc.it>
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
In-Reply-To <021601c59080$52b0a890$8be41d3e@eustahiush>
References <20050723131800.2305A1005A9@lists.intevation.de> <17122.55943.837700.641786@cerise.gclements.plus.com> <021601c59080$52b0a890$8be41d3e@eustahiush>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek Sieczka wrote:

> > The preferred solution is the PNG driver, plus r.in.gdal[1] if you
> > want to import the image as a map
> 
> > (I have no idea why you would
> 
> Because we are talking here about substituting the CELL driver 
> functionality. And as I understand it, CELL driver is for obtaining a Grass
> layer out of the monitor content (not a particular layer, like r.out.gdal,
> or a fragment of layer currently displayed, like r.out.tiff -t) with a 
> colortable stored.

Yeah, but why would you want CELL driver functionality?

> > unlikely to be georeferenced correctly).
> 
> Sure.
> 
> So here all arguments for having CELL driver to Grass61:
> 1. d.out.png + r.in.gdal requires an intermediate file to duplicate the CELL
> driver functionality

Note that d.out.png is just an interface to the PNG driver. It
essentially "grabs" the current monitor by storing its contents using
d.save, then replicating them on the PNG driver.

> 2. r.region is required to georeference the PNG image dump back after 
> r.in.gdal

Exactly the same issue applies to the CELL driver. The resulting map
has an X/Y projection and uses screen coordinates. Also, unless the
aspect ratio of the monitor exactly matches that of the region, the
combination of d.rast and the CELL driver will result in a raster
which has been scaled down and centred.

> 3. if the image dump was over 8 bit, r.composite is required to merge the 3
> layers output by r.in.gdal; moreover, using r.composite, it is unlikely to
> obtain an exact copy of the original PNG image dump

The CELL driver only supports 8-bit colour.

And GRASS sucks at 24-bpp images in general. You can create a 24-bpp
image with r.composite, but it will have 16777216 categories, and the
colour table will have 65536 rules. Processing such images is likely
to be extremely slow.

Colour tables are meant for graphical visualisation of raster maps
where the cell values represent categories or scalar quantities. They
aren't meant to turn raster maps into images.

Colour images should always be processed as separate bands. The only
purpose of r.composite is as a workaround for tools which lack the
ability to use separate colour bands in place of a single map (e.g. 
NVIZ surface colours, v.digit background). Ideally, the tools would be
upgraded, but r.composite serves as a workaround until then.

> 4. alltogether, even if possible to overcome all these problem, CELL driver
> seems much easier in use - one operation instead of 3 or 4.

Other way around. With the CELL driver, you have the added step of
running r.out.png afterwards. AFAIK, the only purpose of the CELL
driver is so that you can use it in conjunction with r.out.* to get
the functionality of the PNG driver.

> My question is if, in the light of above, CELL driver should be ported to 
> Grass61 or not and if it is likely to be done.

No, in both cases.

> Why do we need r.in.png if r.in.gdal provides this functionality?

Because r.in.gdal only provides a subset of r.in.png's functionality. 

-- 
Glynn Clements <glynn@gclements.plus.com>


Wed, Jul 27 2005 21:47:15    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <017901c592e3$e5255df0$2cd21d3e@eustahiush>
From "Maciek Sieczka" <werchowyna@epf.pl>
To "Glynn Clements" <glynn@gclements.plus.com>
Cc <grass-bugs@intevation.de>, "grass devel" <grass5@grass.itc.it>
References <20050723131800.2305A1005A9@lists.intevation.de><17122.55943.837700.641786@cerise.gclements.plus.com><021601c59080$52b0a890$8be41d3e@eustahiush> <17125.62781.832524.674125@cerise.gclements.plus.com>
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
Date Wed, 27 Jul 2005 21:46:01 +0200
MIME-Version 1.0
Content-Type text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding 7bit
X-Priority 3
X-MSMail-Priority Normal
X-Mailer Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus avast! (VPS 0528-4, 2005-07-14), Outbound message
X-Antivirus-Status Clean
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
From: "Glynn Clements" <glynn@gclements.plus.com>

> Maciek Sieczka wrote:
>
>> > The preferred solution is the PNG driver, plus r.in.gdal[1] if you
>> > want to import the image as a map
>>
>> > (I have no idea why you would
>>
>> Because we are talking here about substituting the CELL driver
>> functionality. And as I understand it, CELL driver is for obtaining a
>> Grass
>> layer out of the monitor content (not a particular layer, like
>> r.out.gdal,
>> or a fragment of layer currently displayed, like r.out.tiff -t) with a
>> colortable stored.
>
> Yeah, but why would you want CELL driver functionality?

That's what I wanted to sort out as well - whether we need the CELL driver
in 6.

>> > unlikely to be georeferenced correctly).
>>
>> Sure.
>>
>> So here all arguments for having CELL driver to Grass61:
>> 1. d.out.png + r.in.gdal requires an intermediate file to duplicate the
>> CELL
>> driver functionality
>
> Note that d.out.png is just an interface to the PNG driver. It
> essentially "grabs" the current monitor by storing its contents using
> d.save, then replicating them on the PNG driver.
>
>> 2. r.region is required to georeference the PNG image dump back after
>> r.in.gdal
>
> Exactly the same issue applies to the CELL driver. The resulting map
> has an X/Y projection and uses screen coordinates. Also, unless the
> aspect ratio of the monitor exactly matches that of the region, the
> combination of d.rast and the CELL driver will result in a raster
> which has been scaled down and centred.

Thanks for explaining that. Like I said I never used the CELL driver as it
was never present in 5.7-6.1. I hoped it would store the image neatly
georeferenced.

>> 3. if the image dump was over 8 bit, r.composite is required to merge the
>> 3
>> layers output by r.in.gdal; moreover, using r.composite, it is unlikely
>> to
>> obtain an exact copy of the original PNG image dump
>
> The CELL driver only supports 8-bit colour.

Yuck!

> And GRASS sucks at 24-bpp images in general. You can create a 24-bpp
> image with r.composite, but it will have 16777216 categories, and the
> colour table will have 65536 rules. Processing such images is likely
> to be extremely slow.

Right.

> Colour tables are meant for graphical visualisation of raster maps
> where the cell values represent categories or scalar quantities. They
> aren't meant to turn raster maps into images.
>
> Colour images should always be processed as separate bands. The only
> purpose of r.composite is as a workaround for tools which lack the
> ability to use separate colour bands in place of a single map (e.g.
> NVIZ surface colours, v.digit background). Ideally, the tools would be
> upgraded, but r.composite serves as a workaround until then.

I see. Actually, v.digit is upgraded accordingly already, since one can
use -bgcmd=d.rgb. Neat if nviz could do as well...

>> 4. alltogether, even if possible to overcome all these problem, CELL
>> driver
>> seems much easier in use - one operation instead of 3 or 4.
>
> Other way around. With the CELL driver, you have the added step of
> running r.out.png afterwards. AFAIK, the only purpose of the CELL
> driver is so that you can use it in conjunction with r.out.* to get
> the functionality of the PNG driver.

Ok. I didn't know all the drawbacks of CELL driver (only 8 bit, no
georeferencing, disgusting). Just didn't expect them. My fault, should have
read the 5.4 manual.

>> My question is if, in the light of above, CELL driver should be ported to
>> Grass61 or not and if it is likely to be done.
>
> No, in both cases.

Fine, I'd like to close my report and a similar reported soon after
http://intevation.de/rt/webrt?serial_num=3076&display=History. Anybody
negative?

Should the reminments of CELL driver code in 6.1 code be removed? That would
assure that reports like "d.mon CELL doesn't work" would never happen again.
Thanks
Maciek


Thu, Jul 28 2005 10:32:12    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 28 Jul 2005 10:32:08 +0200
From Markus Neteler <neteler@itc.it>
To Maciek Sieczka <werchowyna@epf.pl>
Cc grass5 developers list <grass5@grass.itc.it>, grass-bugs@intevation.de
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
Message-ID <20050728083208.GE21918@thuille.itc.it>
Mail-Followup-To Maciek Sieczka <werchowyna@epf.pl>, grass5 developers list <grass5@grass.itc.it>, grass-bugs@intevation.de
References <17125.62781.832524.674125@cerise.gclements.plus.com> <017901c592e3$e5255df0$2cd21d3e@eustahiush>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <017901c592e3$e5255df0$2cd21d3e@eustahiush>
User-Agent Mutt/1.4.1i
X-PGP-Key http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Wed, Jul 27, 2005 at 09:46:01PM +0200, Maciek Sieczka wrote:
> From: "Glynn Clements" <glynn@gclements.plus.com>
> >Maciek Sieczka wrote:
...
> >Exactly the same issue applies to the CELL driver. The resulting map
> >has an X/Y projection and uses screen coordinates. Also, unless the
> >aspect ratio of the monitor exactly matches that of the region, the
> >combination of d.rast and the CELL driver will result in a raster
> >which has been scaled down and centred.
> 
> Thanks for explaining that. Like I said I never used the CELL driver as it
> was never present in 5.7-6.1. I hoped it would store the image neatly
> georeferenced.

Hi Maciek,

you could write a simple script [1]:

- if no frames are visible in the monitor, generate also a
  PNG world file.
- export with PNG driver
- reimport with r.in.gdal (which recognizes the PNG world file)

Not very fancy, but definitly better than the old CELL driver.

Markus

[1] Learning a bit of script programming takes a few hours
    since you can start from existing scripts


Wed, Aug 31 2005 20:48:47    Area changed to grass6 by mneteler  
Wed, Aug 31 2005 23:19:32    Request 3076 merged into 3011 by mneteler (as #3076)  
Fri, Sep 2 2005 18:38:41    User changed to harterc1@comcast.net,werchowyna@epf.pl by msieczka  
Tue, Oct 25 2005 07:56:54    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 25 Oct 2005 18:56:22 +1300
From Hamish <hamish_nospam@yahoo.com>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc werchowyna@epf.pl, glynn@gclements.plus.com, grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
Message-Id <20051025185622.0cdf93a5.hamish_nospam@yahoo.com>
In-Reply-To <Pine.LNX.4.60.0507242046070.16941@agrippa.ukshells.co.uk>
References <20050723131800.2305A1005A9@lists.intevation.de> <17122.55943.837700.641786@cerise.gclements.plus.com> <021601c59080$52b0a890$8be41d3e@eustahiush> <Pine.LNX.4.60.0507242046070.16941@agrippa.ukshells.co.uk>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
On Sun, 24 Jul 2005 20:54:13 +0100 (BST)
Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

> > Because we are talking here about substituting the CELL driver 
> > functionality. And as I understand it, CELL driver is for obtaining
> > a  Grass layer out of the monitor content (not a particular layer,
> > like  r.out.gdal, or a fragment of layer currently displayed, like
> > r.out.tiff -t) with a colortable stored.
> 
> The only thing I can think that would be useful for was before there
> were  direct monitor output methods like the PNG driver, you could
> write the  monitor to a GRASS raster layer and then use r.out.tiff or
> whatever to get it into an output file.
..
> But I can't think of a reason why you would want a monitor image as a 
> GRASS raster; rather I would put it that it is the CELL driver that 
> requires two images to get to an output graphics file.
..
> It makes it easy to convert a monitor image into a GRASS raster, but
> what  use is it once you've got it there? I feel it is an historical 
> anachronism.


for the record, an example and work around for this situation.

ps.map will only take one raster for an input image. recently I wanted
to create a hard copy which overlayed one raster image over another
(land+sea satellite images butted up against each other using NULLs).
Each raster had its own unreconcilable color table so I couldn't use
r.patch, and using both the 'rgb' and 'raster' ps.map commands still
would only let me show one raster.

The solution was to set GRASS_WIDTH and GRASS_HEIGHT to the rows &
columns given by g.region, use the PNG driver to dump to a 24-bit image,
reload that rather large image with r.in.gdal, reset the imported maps'
bounds with r.region (trivial as it matched the originial region), then
use d.rgb and ps.map's "rgb" command to display the whole thing. Having
a CELL driver might have made it slightly easier, but more obscure to
use and not useful enough to justify maintaining the code IMO.


Hamish


Tue, Oct 25 2005 21:28:46    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17246.34661.452697.826653@cerise.gclements.plus.com>
Date Tue, 25 Oct 2005 20:28:37 +0100
To Hamish <hamish_nospam@yahoo.com>
Cc Paul Kelly <paul-grass@stjohnspoint.co.uk>, werchowyna@epf.pl, grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
In-Reply-To <20051025185622.0cdf93a5.hamish_nospam@yahoo.com>
References <20050723131800.2305A1005A9@lists.intevation.de> <17122.55943.837700.641786@cerise.gclements.plus.com> <021601c59080$52b0a890$8be41d3e@eustahiush> <Pine.LNX.4.60.0507242046070.16941@agrippa.ukshells.co.uk> <20051025185622.0cdf93a5.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Hamish wrote:

> > But I can't think of a reason why you would want a monitor image as a 
> > GRASS raster; rather I would put it that it is the CELL driver that 
> > requires two images to get to an output graphics file.
> ..
> > It makes it easy to convert a monitor image into a GRASS raster, but
> > what  use is it once you've got it there? I feel it is an historical 
> > anachronism.
> 
> for the record, an example and work around for this situation.
> 
> ps.map will only take one raster for an input image. recently I wanted
> to create a hard copy which overlayed one raster image over another
> (land+sea satellite images butted up against each other using NULLs).
> Each raster had its own unreconcilable color table so I couldn't use
> r.patch, and using both the 'rgb' and 'raster' ps.map commands still
> would only let me show one raster.

Yep; "masked" images are a relatively new feature, only available in
PostScript level 3.

> The solution was to set GRASS_WIDTH and GRASS_HEIGHT to the rows &
> columns given by g.region, use the PNG driver to dump to a 24-bit image,
> reload that rather large image with r.in.gdal, reset the imported maps'
> bounds with r.region (trivial as it matched the originial region), then
> use d.rgb and ps.map's "rgb" command to display the whole thing. Having
> a CELL driver might have made it slightly easier, but more obscure to
> use and not useful enough to justify maintaining the code IMO.

I would have thought it easier to do:

	r.mapcalc <<EOF
	  out.r = if(isnull(top),r#bottom,r#top)
	  out.g = if(isnull(top),g#bottom,g#top)
	  out.b = if(isnull(top),b#bottom,b#top)
	EOF

-- 
Glynn Clements <glynn@gclements.plus.com>


Wed, Oct 26 2005 02:22:15    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 26 Oct 2005 13:21:56 +1300
From Hamish <hamish_nospam@yahoo.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3011] (grass) d.mon CELL doesn't work
Message-Id <20051026132156.72fd905f.hamish_nospam@yahoo.com>
In-Reply-To <17246.34661.452697.826653@cerise.gclements.plus.com>
References <20050723131800.2305A1005A9@lists.intevation.de> <17122.55943.837700.641786@cerise.gclements.plus.com> <021601c59080$52b0a890$8be41d3e@eustahiush> <Pine.LNX.4.60.0507242046070.16941@agrippa.ukshells.co.uk> <20051025185622.0cdf93a5.hamish_nospam@yahoo.com> <17246.34661.452697.826653@cerise.gclements.plus.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> > The solution was to set GRASS_WIDTH and GRASS_HEIGHT to the rows &
> > columns given by g.region, use the PNG driver to dump to a 24-bit
> > image, reload that rather large image with r.in.gdal, reset the
> > imported maps' bounds with r.region (trivial as it matched the
> > originial region), then use d.rgb and ps.map's "rgb" command to
> > display the whole thing. Having a CELL driver might have made it
> > slightly easier, but more obscure to use and not useful enough to
> > justify maintaining the code IMO.
> 
> I would have thought it easier to do:
> 
> 	r.mapcalc <<EOF
> 	  out.r = if(isnull(top),r#bottom,r#top)
> 	  out.g = if(isnull(top),g#bottom,g#top)
> 	  out.b = if(isnull(top),b#bottom,b#top)
> 	EOF


Indeed, much less circuitous. Multiband though so would need to run
r.composite first or:

r.mapcalc <<EOF
   out.r = if(isnull(land_mask), r#sea.r, r#land.r)
   out.g = if(isnull(land_mask), g#sea.g, g#land.g)
   out.b = if(isnull(land_mask), b#sea.b, b#land.b)
EOF


thanks for the tip,
Hamish


Fri, Jun 23 2006 21:47:37    Status changed to resolved by mbarton  
Fri, Jun 23 2006 21:47:37    Mail sent by mbarton  
The CELL driver was never ported to GRASS 6 and AFAIK has been deprecated.

Michael
Tue, Sep 26 2006 18:34:58    Comments added by guest  
Good Luck! http://xoomer.alice.it/pik0/poker-rooms/
Tue, Sep 26 2006 22:39:58    Comments added by guest  
Cool design http://xoomer.alice.it/pik0/razz-poker/
Wed, Sep 27 2006 01:24:52    Comments added by guest  
Great work on website. <a href="http://xoomer.alice.it/pik0/rules-of-poker/">rules
of poker</a> [url=http://xoomer.alice.it/pik0/rules-of-poker/]rules of poker[/url]
http://xoomer.alice.it/pik0/rules-of-poker/
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request