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

GRASS GIS GRASS GIS developer
1

I forgot to cc to grassdev list so here is my response to Michael
Helena

Begin forwarded message:

From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Date: August 26, 2007 12:46:50 AM EDT
To: Michael Barton <michael.barton@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@PERMANENT
0
map elevation.10m@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@PERMANENT
#0000ff
2
1
surf*1188064015
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

2

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

--
Bob Covill
Tekmap Consulting

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

3

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@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@unity.ncsu.edu>
Date: August 26, 2007 12:46:50 AM EDT
To: Michael Barton <michael.barton@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@PERMANENT
0
map elevation.10m@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@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@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

4

Michael Barton wrote:

I don't know enough about xml (either creating or parsing in TclTk) to
implement this, although it sounds like a viable idea otherwise.

As NVIZ is a hybrid C+Tcl/Tk application, you can use an external
library (e.g. libxml) for parsing.

Parsing XML in Tcl isn't viable, IMHO.

--
Glynn Clements <glynn@gclements.plus.com>

5

AFAICT, the current situation is that NVIZ will not properly read the state
file that it writes. To 'fix' it to read it with the current file format and
code approach will result in an incomplete 'fix' in that it still won't read
parts of the state file properly.

XML is a potentially good idea, but requires an external library AND I don't
know XML well enough to implement this.

I *think* I can fix it so that NVIZ in GRASS 6.3 can properly read and
configure itself from a state file. BUT, I need to change the state file
format a little bit to make it parseable. Basically, I need to add section
delimiters (e.g., "start surf", "end surf").

Should I go ahead and do this if I can?

Alternatively, if someone else would like to take this on, I'd be more than
happy.

Michael

On 8/27/07 12:31 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

I don't know enough about xml (either creating or parsing in TclTk) to
implement this, although it sounds like a viable idea otherwise.

As NVIZ is a hybrid C+Tcl/Tk application, you can use an external
library (e.g. libxml) for parsing.

Parsing XML in Tcl isn't viable, IMHO.

__________________________________________
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

6

On Tuesday 28 August 2007 11:43, Michael Barton wrote:

AFAICT, the current situation is that NVIZ will not properly read the state
file that it writes. To 'fix' it to read it with the current file format
and code approach will result in an incomplete 'fix' in that it still won't
read parts of the state file properly.

XML is a potentially good idea, but requires an external library AND I
don't know XML well enough to implement this.

My 2 cents here. If we are using XML in other parts of GRASS (via external
parsing libs) I think that it would be good to standardize on some flavor of
XML for any misc. things like the NVIZ state file. XML is simple to read in a
text editor, simple to parse with external tools, and simple to read/write
with the appropriate libs.

I *think* I can fix it so that NVIZ in GRASS 6.3 can properly read and
configure itself from a state file. BUT, I need to change the state file
format a little bit to make it parseable. Basically, I need to add section
delimiters (e.g., "start surf", "end surf").

This would be fairly simple in XML:

<surface>
  <id>1</id>
  <name>elevation</name>
  <source>elev@mapset></source>
  <colormap>elev@mapset</colormap>

  ... other properties
</surface>

this type of construct could be used to define all of the pieces in the
statefile, so that they can be *directly* read from the document tree:

get/set methods work on:
surface->id->property->value

Should I go ahead and do this if I can?

Alternatively, if someone else would like to take this on, I'd be more than
happy.

thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

Thanks for the hard work Michael,

Dylan

Michael

On 8/27/07 12:31 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
> Michael Barton wrote:
>> I don't know enough about xml (either creating or parsing in TclTk) to
>> implement this, although it sounds like a viable idea otherwise.
>
> As NVIZ is a hybrid C+Tcl/Tk application, you can use an external
> library (e.g. libxml) for parsing.
>
> Parsing XML in Tcl isn't viable, IMHO.

__________________________________________
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
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

7

On 8/28/07 12:09 PM, "Dylan Beaudette" <dylan.beaudette@gmail.com> wrote:

On Tuesday 28 August 2007 11:43, Michael Barton wrote:

AFAICT, the current situation is that NVIZ will not properly read the state
file that it writes. To 'fix' it to read it with the current file format
and code approach will result in an incomplete 'fix' in that it still won't
read parts of the state file properly.

XML is a potentially good idea, but requires an external library AND I
don't know XML well enough to implement this.

My 2 cents here. If we are using XML in other parts of GRASS (via external
parsing libs) I think that it would be good to standardize on some flavor of
XML for any misc. things like the NVIZ state file. XML is simple to read in a
text editor, simple to parse with external tools, and simple to read/write
with the appropriate libs.

snip snip ...

thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

Indeed! Summer is over and my time is short too.

Unless someone that does have expertise in XML and time to do it is out
there, I propose to fix this with minimal changes in the current, simple
ascii state file for the upcoming 6.3 release.

We should rethink this for any subsequent releases, including 7. I don't
want to keep saying that we'll do it better in wxPython, but there are
available xml parsers there (e.g., SAX) that would make this easier. But
again, it will depend on available expertise.

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

8

On Wed, 2007-08-29 at 08:32 -0700, Michael Barton wrote:

On 8/28/07 12:09 PM, "Dylan Beaudette" <dylan.beaudette@gmail.com> wrote:

> On Tuesday 28 August 2007 11:43, Michael Barton wrote:
>> AFAICT, the current situation is that NVIZ will not properly read the state
>> file that it writes. To 'fix' it to read it with the current file format
>> and code approach will result in an incomplete 'fix' in that it still won't
>> read parts of the state file properly.
>>
>> XML is a potentially good idea, but requires an external library AND I
>> don't know XML well enough to implement this.
>
> My 2 cents here. If we are using XML in other parts of GRASS (via external
> parsing libs) I think that it would be good to standardize on some flavor of
> XML for any misc. things like the NVIZ state file. XML is simple to read in a
> text editor, simple to parse with external tools, and simple to read/write
> with the appropriate libs.
>
snip snip ...
>
> thats the kicker... I do not know enough about XML in a C environment to do
> this / and a MS thesis is looming over my head right now... Sorry!
>

Indeed! Summer is over and my time is short too.

Unless someone that does have expertise in XML and time to do it is out
there, I propose to fix this with minimal changes in the current, simple
ascii state file for the upcoming 6.3 release.

If there is an easy fix, you may as well apply it for the upcoming
release. There is probably no point in adding an XML parser to the TCL
interface, as its days are probably numbered.

We should rethink this for any subsequent releases, including 7. I don't
want to keep saying that we'll do it better in wxPython, but there are
available xml parsers there (e.g., SAX) that would make this easier. But
again, it will depend on available expertise.

A number of UI's (GTK(glib), C#, ...) have their own XML parser which
could be taken advantage of when nviz is moved to a new interface. As a
proof of concept I have been playing around with the OpenGL GTK
interface GtkGLExt ( http://www.k-3d.org/gtkglext/Main_Page ) to view
and navigate GRASS data via ogsf. It works fine.

--
Bob

9

Bob Covill wrote:

> > thats the kicker... I do not know enough about XML in a C environment to do
> > this / and a MS thesis is looming over my head right now... Sorry!
> >
>
> Indeed! Summer is over and my time is short too.
>
> Unless someone that does have expertise in XML and time to do it is out
> there, I propose to fix this with minimal changes in the current, simple
> ascii state file for the upcoming 6.3 release.

If there is an easy fix, you may as well apply it for the upcoming
release. There is probably no point in adding an XML parser to the TCL
interface, as its days are probably numbered.

Agreed. If wxPython is used for a new interface, the core Python
libraries include XML parsing.

> We should rethink this for any subsequent releases, including 7. I don't
> want to keep saying that we'll do it better in wxPython, but there are
> available xml parsers there (e.g., SAX) that would make this easier. But
> again, it will depend on available expertise.

A number of UI's (GTK(glib), C#, ...) have their own XML parser which
could be taken advantage of when nviz is moved to a new interface. As a
proof of concept I have been playing around with the OpenGL GTK
interface GtkGLExt ( http://www.k-3d.org/gtkglext/Main_Page ) to view
and navigate GRASS data via ogsf. It works fine.

Personally, I'd suggest using an interpreted language for programs
which are primarily user interfaces. It makes it much easier for users
to add tweaks for their specific needs. FWIW, wxPython includes a
GLCanvas class (analogous to Togl).

Do you have any code available? In terms of replacing NVIZ, it would
be useful to have a relatively simple example of how to use the OGSF
library; NVIZ itself is far too complex for that.

--
Glynn Clements <glynn@gclements.plus.com>

10

On Thu, 2007-08-30 at 03:56 +0100, Glynn Clements wrote:

Bob Covill wrote:

> > > thats the kicker... I do not know enough about XML in a C environment to do
> > > this / and a MS thesis is looming over my head right now... Sorry!
> > >
> >
> > Indeed! Summer is over and my time is short too.
> >
> > Unless someone that does have expertise in XML and time to do it is out
> > there, I propose to fix this with minimal changes in the current, simple
> > ascii state file for the upcoming 6.3 release.
>
> If there is an easy fix, you may as well apply it for the upcoming
> release. There is probably no point in adding an XML parser to the TCL
> interface, as its days are probably numbered.

Agreed. If wxPython is used for a new interface, the core Python
libraries include XML parsing.

> > We should rethink this for any subsequent releases, including 7. I don't
> > want to keep saying that we'll do it better in wxPython, but there are
> > available xml parsers there (e.g., SAX) that would make this easier. But
> > again, it will depend on available expertise.
>
> A number of UI's (GTK(glib), C#, ...) have their own XML parser which
> could be taken advantage of when nviz is moved to a new interface. As a
> proof of concept I have been playing around with the OpenGL GTK
> interface GtkGLExt ( http://www.k-3d.org/gtkglext/Main_Page ) to view
> and navigate GRASS data via ogsf. It works fine.

Personally, I'd suggest using an interpreted language for programs
which are primarily user interfaces. It makes it much easier for users
to add tweaks for their specific needs. FWIW, wxPython includes a
GLCanvas class (analogous to Togl).

Unfortunately, I have never successfully compiled the the version of
wxPython required for the GRASS UI. I have tried a couple of times, but
eventually given up!

Do you have any code available? In terms of replacing NVIZ, it would
be useful to have a relatively simple example of how to use the OGSF
library; NVIZ itself is far too complex for that.

I have uploaded my grass_gtk Glade project which includes the ogsf code
to http://www.tekmap.ns.ca/tekmap_download/grass_gtk.tar.bz2 . The ogsf
calls are made in src/visualization. These include ogsf initialization,
raster loading, vector loading, setting lights, fast draw, and full
draw, navigation, etc. For example, to load a raster ....
new_id = GS_new_surface();
ret = GS_load_att_map(new_id, name, ATT_TOPO);
...
  calc resolutions
...
GS_set_drawres(new_id, max2, max2, max, max);
GS_set_drawmode(new_id, DM_GOURAUD | DM_POLY | DM_GRID_SURF );
ret = GS_load_att_map(new_id, name, ATT_COLOR); /* set color */
ret = GS_set_att_const(new_id, ATT_TRANSP, 0.0);
GS_set_global_exag(5.0);
GS_set_focus_center_map(new_id);

To move to a view position ...
tmp[0] = 100.;
tmp[1] = 100.;
tmp[2] = 2500.;
GS_moveto(tmp);

Hope this helps.

--
Bob

11

Thanks for making this available Bob. There has been considerable progress
recently in compiling wxPython on various systems by folks on the dev list,
and a number of new pre-compiled packages out.

What kind system are you using? Maybe there is someone who can help.

Michael

On 8/30/07 7:24 AM, "Bob Covill" <bcovill@tekmap.ns.ca> wrote:

I have uploaded my grass_gtk Glade project which includes the ogsf code
to http://www.tekmap.ns.ca/tekmap_download/grass_gtk.tar.bz2 . The ogsf
calls are made in src/visualization. These include ogsf initialization,
raster loading, vector loading, setting lights, fast draw, and full
draw, navigation, etc. For example, to load a raster ....
new_id = GS_new_surface();
ret = GS_load_att_map(new_id, name, ATT_TOPO);
...
calc resolutions
...
GS_set_drawres(new_id, max2, max2, max, max);
GS_set_drawmode(new_id, DM_GOURAUD | DM_POLY | DM_GRID_SURF );
ret = GS_load_att_map(new_id, name, ATT_COLOR); /* set color */
ret = GS_set_att_const(new_id, ATT_TRANSP, 0.0);
GS_set_global_exag(5.0);
GS_set_focus_center_map(new_id);

To move to a view position ...
tmp[0] = 100.;
tmp[1] = 100.;
tmp[2] = 2500.;
GS_moveto(tmp);

Hope this helps.

--
Bob

__________________________________________
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