i created some raster using r.plane
but i am not able to display it, got error:
WARNING: can’t get history information for [myplane45] in mapset [troll]
WARNING: can’t get history information for [myplane45] in mapset [troll]
while executing
“close $rt”
(procedure “DmRaster::display” line 27)
invoked from within
“DmRaster::display $node”
(“raster” arm line 2)
invoked from within
“switch $type {
group {
DmGroup::display $node
}
raster {
DmRaster::display $node
}
labels {
DmLabels::display $node
…”
(procedure “Dm::display_node” line 6)
invoked from within
“Dm::display_node $n”
(procedure “DmGroup::display” line 11)
invoked from within
"DmGroup::display “root” "
(procedure “Dm::display” line 8)
invoked from within
“Dm::display”
(“uplevel” body line 1)
invoked from within
“uplevel #0 $cmd”
(procedure “Button::_release” line 18)
invoked from within
“Button::_release .mainframe.topf.tb0.bbox1.b0”
(command bound to event)
when i use r.out.gdal to export and use r.in.gdal to import this raster again to grass, raster dispalys with any problems
i have grass6.1-cvs on my machine
anyone know how to solve this???
best
maciej
Maciej Tomaszczyk
Polish Geological Institute
Geological Mapping Department
i created some raster using r.plane
but i am not able to display it, got error:
WARNING: can't get history information for [myplane45] in mapset [troll]
WARNING: can't get history information for [myplane45] in mapset [troll]
while executing
"close $rt"
(procedure "DmRaster::display" line 27)
invoked from within
"DmRaster::display $node"
("raster" arm line 2)
invoked from within
"switch $type {
group {
DmGroup::display $node
}
raster {
DmRaster::display $node
}
labels {
DmLabels::display $node
.."
(procedure "Dm::display_node" line 6)
invoked from within
"Dm::display_node $n"
(procedure "DmGroup::display" line 11)
invoked from within
"DmGroup::display "root" "
(procedure "Dm::display" line 8)
invoked from within
"Dm::display"
("uplevel" body line 1)
invoked from within
"uplevel \#0 $cmd"
(procedure "Button::_release" line 18)
invoked from within
"Button::_release .mainframe.topf.tb0.bbox1.b0"
(command bound to event)
when i use r.out.gdal to export and use r.in.gdal to import this raster again to grass, raster dispalys with any problems
i have grass6.1-cvs on my machine
anyone know how to solve this???
I confirm - d.m and gis.m (current CVS) fail to display r.plane output
and they issue the above warning. d.rast works ok though.
I noticed that the history file created by r.plane is shorter than
minimum 8 lines I observed so far in case of other raster modules - only
5 lines. As an effect, r.info fails to report any history.
Maciej,
A workaround is to use r.support and answer "y" to "Edit the history
file for [map1]? (y/n) [n]", then ESC+ENTER twice and ENTER. Or to edit
the history file manually adding 4 empty lines.
Thanl's for letting now. Please fill a bug report about that. I'm not
sure if it is d.m/gis.m fault (being to strict about history missing) or
r.plane (that fails to create a valid history file). I guess that both
behave wrong here.
On Sat, Jul 15, 2006 at 07:04:38PM +0200, Maciej Sieczka wrote:
Maciej Tomaszczyk napisa?(a):
> i created some raster using r.plane
> but i am not able to display it, got error:
>
>
>
> WARNING: can't get history information for [myplane45] in mapset [troll]
> WARNING: can't get history information for [myplane45] in mapset [troll]
> while executing
...
>
> when i use r.out.gdal to export and use r.in.gdal to import this raster again to grass, raster dispalys with any problems
> i have grass6.1-cvs on my machine
> anyone know how to solve this???
I confirm - d.m and gis.m (current CVS) fail to display r.plane output
and they issue the above warning. d.rast works ok though.
I noticed that the history file created by r.plane is shorter than
minimum 8 lines I observed so far in case of other raster modules - only
5 lines. As an effect, r.info fails to report any history.
Looking at scripts/r.plane/r.plane shows that an undesired
method of generating the history is used. This must be
changed. Apparently it is a bug in r.plane and not in
the d.m/gis.m managers.
On Sat, Jul 15, 2006 at 07:19:11PM +0200, Markus Neteler wrote:
On Sat, Jul 15, 2006 at 07:04:38PM +0200, Maciej Sieczka wrote:
> Maciej Tomaszczyk napisa?(a):
>
> > i created some raster using r.plane
> > but i am not able to display it, got error:
> >
> >
> >
> > WARNING: can't get history information for [myplane45] in mapset [troll]
> > WARNING: can't get history information for [myplane45] in mapset [troll]
> > while executing
...
> >
> > when i use r.out.gdal to export and use r.in.gdal to import this raster again to grass, raster dispalys with any problems
> > i have grass6.1-cvs on my machine
> > anyone know how to solve this???
>
> I confirm - d.m and gis.m (current CVS) fail to display r.plane output
> and they issue the above warning. d.rast works ok though.
>
> I noticed that the history file created by r.plane is shorter than
> minimum 8 lines I observed so far in case of other raster modules - only
> 5 lines. As an effect, r.info fails to report any history.
>
Looking at scripts/r.plane/r.plane shows that an undesired
method of generating the history is used. This must be
changed. Apparently it is a bug in r.plane and not in
the d.m/gis.m managers.
Fixed in CVS for both 6.1-HEAD and 6.1.0-Branch (for beta2 or RC1).
I have substituted the broken hist file creation by
r.support calls.
Looking at scripts/r.plane/r.plane shows that an undesired
method of generating the history is used. This must be
changed. Apparently it is a bug in r.plane and not in
the d.m/gis.m managers.
Fixed in CVS for both 6.1-HEAD and 6.1.0-Branch (for beta2 or RC1).
I have substituted the broken hist file creation by
r.support calls.
I quickly tried in d.m and it works now.
Thanks for fixing this. The question remains why gis.m/d.m fails to
display history-less a rasters while d.rast displays them fine?
>> Looking at scripts/r.plane/r.plane shows that an undesired
>> method of generating the history is used. This must be
>> changed. Apparently it is a bug in r.plane and not in
>> the d.m/gis.m managers.
>
> Fixed in CVS for both 6.1-HEAD and 6.1.0-Branch (for beta2 or RC1).
> I have substituted the broken hist file creation by
> r.support calls.
>
> I quickly tried in d.m and it works now.
Thanks for fixing this. The question remains why gis.m/d.m fails to
display history-less a rasters while d.rast displays them fine?
see my message on the devel list 7-10 days ago about the same kind of
errors if the raster's cats/ file is missing, but if drawn with d.rast
it displays without complaint. I don't think it is necessarily a bug for
the software to complain when it comes across a broken map, but it would
be nice to understand why it acts differently.
Yea. That's weird. Is it a d.rgb thing? If there is a drape map, the GUI
switches from d.rast to d.rgb.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 17 Jul 2006 20:47:57 +1200
To: Maciej Sieczka <tutey@o2.pl>
Cc: <grassuser@grass.itc.it>, <michael.barton@asu.edu>
Subject: Re: [GRASS-user] r.plane raster display problem
Maciej Sieczka wrote:
Looking at scripts/r.plane/r.plane shows that an undesired
method of generating the history is used. This must be
changed. Apparently it is a bug in r.plane and not in
the d.m/gis.m managers.
Fixed in CVS for both 6.1-HEAD and 6.1.0-Branch (for beta2 or RC1).
I have substituted the broken hist file creation by
r.support calls.
I quickly tried in d.m and it works now.
Thanks for fixing this. The question remains why gis.m/d.m fails to
display history-less a rasters while d.rast displays them fine?
see my message on the devel list 7-10 days ago about the same kind of
errors if the raster's cats/ file is missing, but if drawn with d.rast
it displays without complaint. I don't think it is necessarily a bug for
the software to complain when it comes across a broken map, but it would
be nice to understand why it acts differently.
>>>> Looking at scripts/r.plane/r.plane shows that an undesired
>>>> method of generating the history is used. This must be
>>>> changed. Apparently it is a bug in r.plane and not in
>>>> the d.m/gis.m managers.
>>>
>>> Fixed in CVS for both 6.1-HEAD and 6.1.0-Branch (for beta2 or
>>> RC1). I have substituted the broken hist file creation by
>>> r.support calls.
>>>
>>> I quickly tried in d.m and it works now.
>>
>> Thanks for fixing this. The question remains why gis.m/d.m fails to
>> display history-less a rasters while d.rast displays them fine?
Hamish:
> see my message on the devel list 7-10 days ago about the same kind
> of errors if the raster's cats/ file is missing, but if drawn with
> d.rast it displays without complaint. I don't think it is
> necessarily a bug for the software to complain when it comes across
> a broken map, but it would be nice to understand why it acts
> differently.
Michael:
Yea. That's weird. Is it a d.rgb thing? If there is a drape map, the
GUI switches from d.rast to d.rgb.
in spearfish: (or wherever)
r.mapcalc test1=1
d.mon x0
d.rast test1
[ok]
gis.m: display raster
[ok]
cd $MAPSET/
mv hist/test1 hist/test1.old
d.redraw
[ok]
gis.m: redraw
Error: WARNING: can't get history information for [test1] in mapset
[user1]
[Detail:]
WARNING: can't get history information for [test1] in mapset [user1]
WARNING: can't get history information for [test1] in mapset [user1]
while executing
"close $rt"
(procedure "GmRaster::display" line 40)
invoked from within
"GmRaster::display $node $mod"
("raster" arm line 2)
invoked from within
"switch $type {
group {
GmGroup::display $node $mod
}
raster {
GmRaster::display $node $mod
}
labels {
GmLabels::disp..."
(procedure "GmTree::display_node" line 7)
invoked from within
"GmTree::display_node $n $mod"
(procedure "GmGroup::display" line 25)
invoked from within
"GmGroup::display "root" $mod"
(procedure "MapCanvas::runprograms" line 30)
invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
(procedure "MapCanvas::drawmap" line 43)
invoked from within
"MapCanvas::drawmap $mon"
(procedure "MapCanvas::display_server" line 9)
invoked from within
"MapCanvas::display_server"
("after" script)
then if gets stuck with "please wait.." at the bottom of the Map Display
1 window.
if you move away the cats/ file you get:
WARNING: category support for [test1] in mapset [user1] missing
WARNING: category support for [test1] in mapset [user1] missing
while executing
"close $rt"
(procedure "GmRaster::display" line 40)
invoked from within
"GmRaster::display $node $mod"
("raster" arm line 2)
Could it be a problem of it sending error messages to the wrong
place--stdout??
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 18 Jul 2006 12:09:38 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] r.plane raster display problem
Looking at scripts/r.plane/r.plane shows that an undesired
method of generating the history is used. This must be
changed. Apparently it is a bug in r.plane and not in
the d.m/gis.m managers.
Fixed in CVS for both 6.1-HEAD and 6.1.0-Branch (for beta2 or
RC1). I have substituted the broken hist file creation by
r.support calls.
I quickly tried in d.m and it works now.
Thanks for fixing this. The question remains why gis.m/d.m fails to
display history-less a rasters while d.rast displays them fine?
Hamish:
see my message on the devel list 7-10 days ago about the same kind
of errors if the raster's cats/ file is missing, but if drawn with
d.rast it displays without complaint. I don't think it is
necessarily a bug for the software to complain when it comes across
a broken map, but it would be nice to understand why it acts
differently.
Michael:
Yea. That's weird. Is it a d.rgb thing? If there is a drape map, the
GUI switches from d.rast to d.rgb.
in spearfish: (or wherever)
r.mapcalc test1=1
d.mon x0
d.rast test1
[ok]
gis.m: display raster
[ok]
cd $MAPSET/
mv hist/test1 hist/test1.old
d.redraw
[ok]
gis.m: redraw
Error: WARNING: can't get history information for [test1] in mapset
[user1]
[Detail:]
WARNING: can't get history information for [test1] in mapset [user1]
WARNING: can't get history information for [test1] in mapset [user1]
while executing
"close $rt"
(procedure "GmRaster::display" line 40)
invoked from within
"GmRaster::display $node $mod"
("raster" arm line 2)
invoked from within
"switch $type {
group {
GmGroup::display $node $mod
}
raster {
GmRaster::display $node $mod
}
labels {
GmLabels::disp..."
(procedure "GmTree::display_node" line 7)
invoked from within
"GmTree::display_node $n $mod"
(procedure "GmGroup::display" line 25)
invoked from within
"GmGroup::display "root" $mod"
(procedure "MapCanvas::runprograms" line 30)
invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
(procedure "MapCanvas::drawmap" line 43)
invoked from within
"MapCanvas::drawmap $mon"
(procedure "MapCanvas::display_server" line 9)
invoked from within
"MapCanvas::display_server"
("after" script)
then if gets stuck with "please wait.." at the bottom of the Map Display
1 window.
if you move away the cats/ file you get:
WARNING: category support for [test1] in mapset [user1] missing
WARNING: category support for [test1] in mapset [user1] missing
while executing
"close $rt"
(procedure "GmRaster::display" line 40)
invoked from within
"GmRaster::display $node $mod"
("raster" arm line 2)
>>>> Thanks for fixing this. The question remains why gis.m/d.m fails to
>>>> display history-less a rasters while d.rast displays them fine?
>
> Hamish:
>>> see my message on the devel list 7-10 days ago about the same kind
>>> of errors if the raster's cats/ file is missing, but if drawn with
>>> d.rast it displays without complaint. I don't think it is
>>> necessarily a bug for the software to complain when it comes across
>>> a broken map, but it would be nice to understand why it acts
>>> differently.
Michael:
Could it be a problem of it sending error messages to the wrong
place--stdout??