[GRASS-dev] Replacement of NVIZ

[Glynn Clements]

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)?

Beyond that, NVIZ is pretty ugly, structurally.

> 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.

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.

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.

-- 
Glynn Clements <glynn at gclements.plus.com>