Hi Micheal; You might recall the eamil I sent last November, indicating that the load/save State File was broken.
In the email I suggested changing the state file to an XML based file. This would allow greater portability to newer nviz viewer(s). It would be more flexible as features are added to a nviz viewer. It could also support saving and loading the keyframe animations. With XML a program could also added the creates "State Files" with a set view. For example load raster "elevation" with 5x exag. and view from azi. 195 deg. and altitude 45 deg.. -- Bob On Sun, 2007-08-26 at 11:52 -0400, Helena Mitasova wrote: > I forgot to cc to grassdev list so here is my response to Michael > Helena > > Begin forwarded message: > > > From: Helena Mitasova <[EMAIL PROTECTED]> > > Date: August 26, 2007 12:46:50 AM EDT > > To: Michael Barton <[EMAIL PROTECTED]> > > Subject: Re: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows, nviz > > > > Michael, > > > > I think that you are right with your diagnosis of the problem. > > It is really in reading - GRASS6.2.1 (dec. 2006) correctly reads > > state files saved by 6.2.1 but also those saved by 6.3 (april 2007) > > (although the 6.3 is missing the light info, but size of the window > > and viewing position is loaded correctly in 6.2.1). > > GRASS6.3 cannot read correctly neither the 6.2.1 file nor 6.3 file. > > > > But even in 6.2.1 the state file can be loaded only at the beginning > > to have any effect - e.g. > > nviz elevation > > Load state -> teststate.nviz > > works > > > > but if you are working in nviz and then want to load it again - > > it would not resize the window - this may be actually intentional, > > I don't remember. > > > > As for the suggestion to change the formatting of the state file - > > that would be good > > to post to users list to see whether that would be concern > > (it should be easy to update an existing state file). > > > > Both the state file issue and the names of the files in the file > > sequencing tool > > would be very useful to solve so that the landscape evolution can be > > visualized as dynamic surface. We can even > > have multiple surfaces - one showing terrain with erosion and the > > second one showing > > the changing land use with the people represented by dynamic point > > symbols. > > What do you use for viewing the landscape evolution now? > > > > thanks a lot for looking into this, it would be great to have this > > capability back > > as we now have quite a bit of data from various projects and the book > > that would be nice to show as dynamic surfaces, > > > > Helena > > > > Helena Mitasova > > Dept. of Marine, Earth and Atm. Sciences > > 1125 Jordan Hall, NCSU Box 8208, > > Raleigh NC 27695 > > http://skagit.meas.ncsu.edu/~helena/ > > > > > > > > On Aug 25, 2007, at 4:11 PM, Michael Barton wrote: > > > >> Here is an example of what a state file is like for a raster > >> surface and > >> vector lines map. > >> > >> 1 > >> surf*1188064015 > >> map [EMAIL PROTECTED] > >> 0 > >> map [EMAIL PROTECTED] > >> 0 > >> unset > >> 0 > >> unset > >> const 60.000000 > >> unset > >> #888888 > >> 0.000000 0.000000 0.000000 > >> 3 3 > >> 2 2 > >> poly > >> grid_surf > >> gouraud > >> 1 > >> vect*1188064015 > >> [EMAIL PROTECTED] > >> #0000ff > >> 2 > >> 1 > >> surf*1188064015 > >> 0 > >> 0 > >> 400 400 > >> 34.0 > >> 1.615 > >> 6333.66 > >> 0.304 0.696 > >> 1 > >> 9480.000000 6975.000000 1453.245850 > >> > >> The line BEFORE the line starting surf* or vect* is where a new > >> group of > >> parameters go that need to be read by a panel. > >> > >> For example, panel_surf.tcl needs to read everything from the > >> first line > >> (with the number 1, indicating that there is only 1 surface to > >> deal with), > >> up to the line BEFORE "vect*1188064015" (another number 1), where the > >> information on the vector starts. This makes it hard to parse this > >> file into > >> the parts that need to go to the separate panel modules. > >> > >> It looks like it was doing this before by simply letting the > >> general load > >> procedure and each panel load procedure generate umpteen error > >> messages to > >> the terminal while picking out the stuff that each could use from > >> the whole > >> file. This could get mixed up very easily. > >> > >> What's needed is a way to delimit each section: surf, vect, > >> lights, etc. A > >> very easy way to do this would be to begin each section with > >> "start surf" or > >> "start vect" and end with "end surf" or "end vect", and so on. > >> > >> But of course this means changing the format of nviz state files a > >> little. > >> Old files won't be readable without adding start and stop section. > >> On the > >> other hand, they're not readable now and I really wonder how well > >> they could > >> be read in the past with this kind of format. > >> > >> What is your opinion on this? > >> > >> Michael > >> > >> __________________________________________ > >> 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 > >> > >> > > > > _______________________________________________ > grass-dev mailing list > [email protected] > http://grass.itc.it/mailman/listinfo/grass-dev -- Bob Covill Tekmap Consulting email:[EMAIL PROTECTED] web: www.tekmap.ns.ca _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
