[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows, nviz

Mon Aug 27 08:02:12 EDT 2007

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 <hmitaso at unity.ncsu.edu>
> > Date: August 26, 2007 12:46:50 AM EDT
> > To: Michael Barton <michael.barton at asu.edu>
> > 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 elevation.10m at PERMANENT
> >> 0
> >> map elevation.10m at PERMANENT
> >> 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
> >> roads at PERMANENT
> >> #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
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
-- 
Bob Covill
Tekmap Consulting

email:bcovill at tekmap.ns.ca
web: www.tekmap.ns.ca