[GRASS-dev] Google Summer of Code 2008
michael.barton at asu.edu
Thu Feb 21 13:22:06 EST 2008
voice: 480-965-6262; fax: 480-965-7671
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
> 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
> need somebody to mentor the programming part).
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
More information about the grass-dev