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@lists.osgeo.org wrote:
Date: Thu, 21 Feb 2008 09:48:16 -0500
From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Subject: Re: [GRASS-dev] Google Summer of Code 2008
To: GRASS developers list <grass-dev@lists.osgeo.org>
Cc: Wolf Bergenheim <wolf+grass@bergenheim.net>
Message-ID: <4788DE50-9AB8-418C-856C-462BED4F25FC@unity.ncsu.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowedOn 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
FreeGIS.org?
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