[GRASS-dev] Google Summer of Code 2008

[Michael Barton]

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Feb 21, 2008, at 10:00 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Thu, 21 Feb 2008 09:48:16 -0500
> From: Helena Mitasova <hmitaso at unity.ncsu.edu>
> Subject: Re: [GRASS-dev] Google Summer of Code 2008
> To: GRASS developers list <grass-dev at lists.osgeo.org>
> Cc: Wolf Bergenheim <wolf+grass at bergenheim.net>
> Message-ID: <4788DE50-9AB8-418C-856C-462BED4F25FC at unity.ncsu.edu>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Feb 20, 2008, at 2:43 PM, Moritz Lennert wrote:
>
>> Some other ideas:
>>
>>> From the GRASS 7.x ideas collection:
>> - implement file based spatial index (see "Keep topology and
>> spatial index
>> in file instead of in memory" in Radim's Vector ToDo
>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?
>> rev=HEAD&content-type=text/vnd.viewcvs-markup)
>
> I wanted to suggest this one too (this should also remove the need
> for constant rebuilding of spatial index whenever you want to query
> vector data)
> - we should try to find a way how to make this task sound exciting so
> that there
> is an interest to do it - or maybe make it part of some of the vector
> processing topics
> suggested by Wolf.
>
> Another topic that I was thinking about was getting a start for the
> next generation
> visualization tool for GRASS - just a simple demo that can be done
> in 3 months to display surface(s) in 2D and smoothly transfer the
> view into 3D.
> Do we have a potential mentor? (I can be the second mentor, but we  
> would
> need somebody to mentor the programming part).
>
> Helena

I was going to suggest extending v.what to take xy coordinates (single  
xy or line of xy's with a buffer distance to find stuff within that  
buffer distance of the coordinates; set of at least 3 xy's to ID a  
polygon and find the stuff within it).

However, I want to also strongly second Helena's idea. The new  
wxPython GUI is essentially finished. Now it needs testing, bug  
fixing, optimizing, etc.

The one piece of the GUI that is not done is a 2.5+D visualizer along  
the lines of NVIZ. As you know, NVIZ is built with a mix of TclTk, a  
Tk OpenGL widget, and C. What we need is something that will run in  
wxPython instead of TclTk. There are various ways to do this, I'm sure  
with pros and cons. My personal preference for interface is that this  
new tool would visually appear in the following way:

-Start the wxpnviz module and you get a new toolbox window to control  
the N-dimensional view.
-The module will grab any active maps in your layer tree (i.e., the  
ones you are displaying in 2D in the map display) and render them in  
3D -- sort of like the current NVIZ button tries to do in TclTk now.
-The 2.5 or 3D image (i.e., include volumes) appears in the same  
window as the 2D map did, replacing the previous view of the 2D map  
with a 2.5/3D rendered image that is controlled by the toolbox. That  
is, the OpenGL canvas could replace the wx.PseudoDC canvas that used  
for 2D display, for example. You would not have a special N- 
dimensional display window that you need to manage separately from  
other display windows (i.e., don't do it like NVIZ does now).
- All map management would continue to be done through the current  
layer manager, rather than a separate interface (i.e., not the way  
that NVIZ works now).
- The rendering module would also display overlays like grids,  
barscales, and the like in the same way that the 2D manager does.

The ideas is that for the user, you don't need to learn a new  
interface for basic map display management to get a N-dimensional  
visualization. The only new interface to learn would be those tools  
specifically related to the N-dimensional visualization (e.g.,  
rotation, z-exaggeration, lighting, isosurface selection, etc).

The other thing that would be nice for many people would be to have a  
command version of the visualizer that could accept a set of arguments  
(or maybe a configuration file) that controlled the display and  
rendered to a PNG instead of the wxPython display window

Michael