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/ |
|