[GRASS-dev] Replacement of NVIZ

[Michael Barton]

On 4/23/07 11:59 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> Why do you think it is not maintainable? We are maintaining it now and it is
>> far better than equivalent packages in other GIS platforms (if they even
>> exist). There also are likely to be more people with python/wxPython
>> expertise than we now have with TclTk expertise, which bodes well for future
>> maintainability and enhancements.
> 
> How long have we been trying to get "max res PPM" working (or, at
> least, to fail in ways which don't involve rebooting)?

Maybe we should give up on this ;-)

> 
> Beyond that, NVIZ is pretty ugly, structurally.

Agreed. It still uses quite a bit of very old TclTk syntax, as well as some
very clunky ways of doing things (maybe necessitated when it was written).
There is a lot of legacy code in GRASS, simply because it's been around so
long with so many contributors.

> 
>> We should be conservative about taking on **new** code responsibilities
>> unless we have the development team to manage them into the future. But with
>> the development team growing, and inclusion into OSGEO, I don't see any
>> reason to jettison existing GRASS functionality--especially a piece that is
>> so good and has been a key part of GRASS for so long. Many other programs
>> exist that do parts of what GRASS does (GDAL, MySQL, ParaView, GIMP,
>> QCAD)--and sometimes do it with much more sophistication. GRASS brings
>> needed functionality together in an integrated way to provide a rich and
>> complete GIS environment.
> 
> I thought that NVIZ *was* going to be jettisoned in favour of a Python
> version? That process isn't going to retain much of the original code.

Agreed again. There is no point in simply porting the current NVIZ to
wxPython. This is a good chance to improve visualization in general.
However, I'd hate to lose the ability to visualize multidimensional data
within GRASS like we can now--however it is done.

Rather than passing off visualization to other apps, I'd hope we can take
this opportunity to improve how it works in GRASS.

> 
> FWIW, I would be in favour of doing that. Apart from anything else, a
> replacement ought to be much cleaner.
> 
> More generally, when creating an application of that level of
> complexity, structure matters. A lot. It isn't sufficient for the end
> result to work; people need to be able to modify it without first
> having to spend days or even weeks studying the code.

Yes. And documentation helps a lot too.

> 
> Regarding "PyNVIZ", my main suggestion would be to keep the amount of
> C to a bare minimum. Create direct Python bindings for OGSF and write
> the rest in Python. Trying to understand code which is split between
> multiple languages is hard, and debugging it is even worse.

Only dealing with the GUI end of it, I take your word on this.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
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