[GRASS-dev] GRASS 6.3.0 release preparation

GRASS GIS GRASS GIS developer
1

Hi,

i’m using 6.3-cvs on osx

i compile it every 2-3 day on osx
i found a problem running d.nviz from the gis.m button (fly trhough path for NVIZ)
when press the related button i’ve this log :

can’t read “xmonlist”: no such variable
can’t read “xmonlist”: no such variable
while executing
“lindex $xmonlist 0”
(procedure “guarantee_xmon” line 16)
invoked from within
“guarantee_xmon”
(procedure “Gm::fly” line 3)
invoked from within
“Gm::fly”
(“uplevel” body line 1)
invoked from within
“uplevel #0 $cmd”
(procedure “Button::_release” line 18)
invoked from within
“Button::_release .mainframe.topf.tb1.bbox4.b1”
(command bound to event)

runnig d.nviz directly from command line everyting works fine.

to check if it is related to my ststem configuration
i’ve compiled grass 6.2 using the same dependancie that i use for 6.3 release
and i’ve that in grass-6.2
d.nviz works fine using the gis.m button

nice to see that a7.0 is coming :slight_smile:

really thanks to all developpers!!!

Massimo Di Stefano

Il giorno 11/ago/07, alle ore 23:05, Helena Mitasova ha scritto:

On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote:

Hi,

I think that it is time to get out a GRASS 6.3.0 release

(as sort of technology preview). It would be great to

have it ready for FOSS4G2007, say, September.

IMHO, GRASS 6.3-CVS is in a good shape. Thoughts?

Before the release, can somebody please double check that the following works

(most of this I believe was already discussed and should be fixed):

  • nviz: you can add additional surfaces using the Raster surfaces panel without crashing nviz

(please try different resolutions, spatial extent, mapsets)

  • nviz: mask the displayed surface using a selected raster map from within nviz (in my version the

mask only masked the displayed vector data)

  • nviz: save state - you can save the state and then load it and you can start working where you

stoped when you saved your state

  • nviz: when saving the image, that the actual displayed image is saved rather than redrawn image

(for example if you have loaded 4 surfaces and you display only one of them the automatic redraw

during the saving procedure would display all four)

  • nviz: file sequencing tool saves the entire path rather than just the name of raster maps which

nviz then cannot interpret when you try to play the script

I hope that most of this has been already fixed but generally I have a 4 months old nviz on Mac

having more capabilities fully functional than my few weeks old version on RedHat Linux,

so it would be good to test before releasing.

Otherwise GRASS63 is probably in better shape and more systematically tested than any

previous release as both Markus and I ran almost all GRASS commands (not with all options though)

and although there has been some level of frustration, most things work very well.

If you ask me what was the most annoying (but not critica) thing that I have found when using

GRASS under a deadline - then it was the large default size of the centroid symbol in d.vect.

I had to go through large number of vector data when preparing the new data set

and each time I forgot to set the size smaller I got the unreadable mess of overlapping crosses.

So if we could change the default to something smaller - perhaps size 2 rather than 5,

that would be great, because most of the time you really want to see your polygons

not the centroids and they are quite visible at size 2 even with my old eyes

(maybe make the default red as the default fill is grey). This was already

discussed some time ago too.

Helena

Markus

2

Massimo,

Thanks for reporting this. I’ve been following up on your report and found very puzzling behavior, and finally identified the cause. I’ll explain it and offer a couple ideas for a solution.

The d.nviz button is a legacy of d.m because it allows you to interactively create a fly-though path by drawing with a mouse in an xterm display monitor. d.nviz then uses the result to create the path for NVIZ.

In order to make it work with the new display system in the current GUI, the button first attempts to launch an xterm display monitor, using a TclTk procedure “guarantee_xmon”. This procedure runs d.mon -L to see what display monitors are available and launches the first available one. It uses an xmon that is not currently running to avoid overwriting anything that you may be using an active xterm display monitor for. Although something of a kludge, the procedure works OK for the few commands that need it (e.g. r.digit) EXCEPT the d.nviz button.

When the d.nviz button is pressed, a bit of debug code showed that ALL monitors were running and none were available to use for drawing a flight path. This is what is causing the error. The puzzling part is why ALL monitors should be running for the d.nviz button when NO xterm display monitors are running for any other command that needs an xterm.

It turns out that an environmental variable “GRASS_RENDER_IMMEDIATE”, which needs to be set to TRUE at the beginning of a TclTk GUI session for the display environment to work most efficiently, sets all xmons to running. This makes it impossible to open an unused xterm monitor for any command launched from the toolbar.

So what to do…

  1. Remove the nviz button and d.nviz buttons from the toolbar and put them back into the menu somewhere. There is no obvious place to put them (since nviz will display both rasters and vectors), but I guess the file menu would be OK. This should probably be done anyway to make sure a generic version of each command is available somewhere. It would be up to the user to launch an xmon and display a map in it for interactive fly-through creation. But the command would work.

  2. Probably the best solution would be to put the d.nviz button into the mapdisplay toolbar and write a TclTk wrapper for d.nviz. This would let you draw the path on the map display canvas, grab the xy coordinates of each node, and send them to d.nviz for path creation. I don’t know how difficult this would be to do. I’ll look into it and report back. I also don’t have a feel for how widely used this function is to justify the efforts for custom interface design. I’d appreciate any feedback on this.

Michael

On 8/11/07 4:58 PM, “massimo di stefano” massimodisasha@yahoo.it wrote:

Hi,

i’m using 6.3-cvs on osx
i compile it every 2-3 day on osx
i found a problem running d.nviz from the gis.m button (fly trhough path for NVIZ)
when press the related button i’ve this log :

can’t read “xmonlist”: no such variable
can’t read “xmonlist”: no such variable
while executing
“lindex $xmonlist 0”
(procedure “guarantee_xmon” line 16)
invoked from within
“guarantee_xmon”
(procedure “Gm::fly” line 3)
invoked from within
“Gm::fly”
(“uplevel” body line 1)
invoked from within
“uplevel #0 $cmd”
(procedure “Button::_release” line 18)
invoked from within
“Button::_release .mainframe.topf.tb1.bbox4.b1”
(command bound to event)

runnig d.nviz directly from command line everyting works fine.

to check if it is related to my ststem configuration
i’ve compiled grass 6.2 using the same dependancie that i use for 6.3 release
and i’ve that in grass-6.2
d.nviz works fine using the gis.m button

nice to see that a7.0 is coming :slight_smile:

really thanks to all developpers!!!

Massimo Di Stefano

Il giorno 11/ago/07, alle ore 23:05, Helena Mitasova ha scritto:

On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote:

Hi,

I think that it is time to get out a GRASS 6.3.0 release

(as sort of technology preview). It would be great to

have it ready for FOSS4G2007, say, September.

IMHO, GRASS 6.3-CVS is in a good shape. Thoughts?

Before the release, can somebody please double check that the following works

(most of this I believe was already discussed and should be fixed):

  • nviz: you can add additional surfaces using the Raster surfaces panel without crashing nviz

(please try different resolutions, spatial extent, mapsets)

  • nviz: mask the displayed surface using a selected raster map from within nviz (in my version the

mask only masked the displayed vector data)

  • nviz: save state - you can save the state and then load it and you can start working where you

stoped when you saved your state

  • nviz: when saving the image, that the actual displayed image is saved rather than redrawn image

(for example if you have loaded 4 surfaces and you display only one of them the automatic redraw

during the saving procedure would display all four)

  • nviz: file sequencing tool saves the entire path rather than just the name of raster maps which

nviz then cannot interpret when you try to play the script

I hope that most of this has been already fixed but generally I have a 4 months old nviz on Mac

having more capabilities fully functional than my few weeks old version on RedHat Linux,

so it would be good to test before releasing.

Otherwise GRASS63 is probably in better shape and more systematically tested than any

previous release as both Markus and I ran almost all GRASS commands (not with all options though)

and although there has been some level of frustration, most things work very well.

If you ask me what was the most annoying (but not critica) thing that I have found when using

GRASS under a deadline - then it was the large default size of the centroid symbol in d.vect.

I had to go through large number of vector data when preparing the new data set

and each time I forgot to set the size smaller I got the unreadable mess of overlapping crosses.

So if we could change the default to something smaller - perhaps size 2 rather than 5,

that would be great, because most of the time you really want to see your polygons

not the centroids and they are quite visible at size 2 even with my old eyes

(maybe make the default red as the default fill is grey). This was already

discussed some time ago too.

Helena

Markus

Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton