I don't know enough about xml (either creating or parsing in TclTk) to implement this, although it sounds like a viable idea otherwise.
Michael On 8/27/07 5:02 AM, "Bob Covill" <[EMAIL PROTECTED]> wrote: > 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 __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and 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
