[GRASS-dev] Google Summer of Code 2008

[WolfgangZ]

Michael Barton schrieb:
> 
> 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

why not to use the python bindings of VTK (http://www.vtk.org) to do 3D 
rendering? It seems to me that VTK is a bit easier to handle than OpenGL 
directly, but my programming skills are not the best.
WolfgangZ