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

Mon Aug 27 12:33:46 EDT 2007

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" <bcovill at tekmap.ns.ca> 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 <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

__________________________________________
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 