We use enthought open source tool suite http://www.enthought.com/ which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for 3D graphics
I think these packages would be well worth having a close look at especially MayaVi2 (Python wrapped VTK) for the 3D graphics.
thanks
Syd
--
/////////////////////////////////////
Syd Visser P.Geo
SJ Geophysics Ltd.
sydv@sjgeophysics.com
www.sjgeophysics.com
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/ which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for 3D graphics
I think these packages would be well worth having a close look at especially MayaVi2 (Python wrapped VTK) for the 3D graphics.
I would like to prefer a C++ grass data server + grass gui plugin for paraview3
to visualize 3d data. This would a nice and fast solution.
Best regards
Soeren
thanks
Syd
Soren
Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more towards MayaVi2 although we use Paraview2.6 extensively but strictly as a viewer.
We find MayaVi2 is also more open to user development thus easier to extend.
Thanks
Syd
Sören Gebbert wrote:
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/ which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for 3D graphics
I think these packages would be well worth having a close look at especially MayaVi2 (Python wrapped VTK) for the 3D graphics.I would like to prefer a C++ grass data server + grass gui plugin for paraview3
to visualize 3d data. This would a nice and fast solution.Best regards
Soerenthanks
Syd
--
/////////////////////////////////////
Syd Visser P.Geo
SJ Geophysics Ltd.
sydv@sjgeophysics.com
www.sjgeophysics.com
Sören Gebbert wrote:
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/ which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for 3D graphics
I think these packages would be well worth having a close look at especially MayaVi2 (Python wrapped VTK) for the 3D graphics.I would like to prefer a C++ grass data server + grass gui plugin for paraview3
to visualize 3d data. This would a nice and fast solution.Best regards
Soerenthanks
Syd
I would also vote for a better connection between grass and vtk. There are direct wrappers to vtk from python, so that Mayavi is obsolete?
Wolfgang
Syd,
Syd Visser schrieb:
Soren
Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more towards MayaVi2 although we use Paraview2.6 extensively but strictly as a viewer.
We find MayaVi2 is also more open to user development thus easier to extend.
I'm developing with VTK and Qt since several years and have used ParaView1-2 for several years.
My experience with MayaVi is little, because the user interface was too horrible.
IMHO ParaView3 is the better choice. It has a sophisticated but very
intuitive user interface and is developed by well known institutes and kitware.
And they are doing a great job. ParaView is designed to visualize huge datasets in parallel.
MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new dependencies (except wxPython).
And for now i'm not able to get even the new grass wxPython gui to run on my debian etch system
because of the dependencies.
ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as well as VTK.
(i still don't understand why wxWidgets and python was choosen for the new grass gui and not Qt
and python ...)
The only thing we need to provide is a data server and gui plugin for ParaView3:
http://www.paraview.org/Wiki/Plugin_HowTo
And when ParaView3 reaches a stable state and i have some spare time i'm
absolutely willingly to implement them!
IMHO the data server and the reader/writer to the grass database
(grass data should be modified with Paraview3 and stored back into the grass database 
if possible)
should be implemented in C++ for performance reasons. I would not use the grass python wrapper
to get the data into a visualization system. The grass raster, voxel and vector functions can be
accessed from C++ code directly.
The data server should provide access to the grass database to read and write raster, volume and vector data.
And ParaView3 should be extended with a nice little Qt gui to access the grass data directly from the toolbar
(like Qgis). We don't need to touch the ParaView3 sources, we only need to implement plugins.
A screenshot of ParaView3 handling grass raster, volume and vector data (exported with the *.out.vtk modules)
is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_Screenshot_grass_data.png
Just my two cents ...
sorry for my English
Best regards
Soeren
Thanks
SydSören Gebbert wrote:
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/ which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for 3D graphics
I think these packages would be well worth having a close look at especially MayaVi2 (Python wrapped VTK) for the 3D graphics.I would like to prefer a C++ grass data server + grass gui plugin for paraview3
to visualize 3d data. This would a nice and fast solution.Best regards
Soerenthanks
Syd
Following up on this and the many other interesting posts to this thread...
I asked if anyone objected to having numpy or scipy (incluing numpy) as a
dependency for the new wxPython GUI. The response has been overwhelmingly in
favor, pointing out the many things possible with this kind of package.
I just want to use it to make nicer plotting easier (e.g., for profiling and
histogramming) in the GUI, but obviously it has other uses. And of course,
there are a number of other even more sophisticated plotting/graphing
packages that also run under wxPython and scipy.
Michael
On 4/22/07 1:36 PM, "Syd Visser" <sydv@sjgeophysics.com> wrote:
We use enthought open source tool suite http://www.enthought.com/ which
contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for
3D graphics
I think these packages would be well worth having a close look at
especially MayaVi2 (Python wrapped VTK) for the 3D graphics.thanks
Syd
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
It's great that we can export GRASS data to be used in high-end
multi-dimensional visualization platforms like Paraview and MayVi2. I've
used Paraview a bit. I wouldn't call it easy or intuitive, but it is quite
sophisticated and powerful--though not particularly fast in my experience.
However, using any of these packages is not a replacement for NVIZ. NVIZ
will let a user quickly and seamlessly render 2, 2.5, 3, and 4 dimensional
data within a GRASS GIS session. This is a real bonus. And NVIZ does this
better than any other rendering engine within a GIS that I've seen. In this
sense, NVIZ has a different goal from Paraview and other dedicated
multidemensional rendering packages.
So I hope that we can get NVIZ ported to wxPython and make it an even more
seamless part of the geospatial visualization tools for GRASS. Making
tighter connections between GRASS and other, external visualization tools is
also a worthy plan--similar to the integration between GRASS and R. But
IMHO, we should not abandon NVIZ or something like it.
Michael
On 4/22/07 4:31 PM, "Sören Gebbert" <soerengebbert@gmx.de> wrote:
Syd,
Syd Visser schrieb:
Soren
Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more
towards MayaVi2 although we use Paraview2.6 extensively but strictly as
a viewer.
We find MayaVi2 is also more open to user development thus easier to
extend.I'm developing with VTK and Qt since several years and have used ParaView1-2
for several years.
My experience with MayaVi is little, because the user interface was too
horrible.
IMHO ParaView3 is the better choice. It has a sophisticated but very
intuitive user interface and is developed by well known institutes and
kitware.
And they are doing a great job. ParaView is designed to visualize huge
datasets in parallel.MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new
dependencies (except wxPython).
And for now i'm not able to get even the new grass wxPython gui to run on my
debian etch system
because of the dependencies.
ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as
well as VTK.
(i still don't understand why wxWidgets and python was choosen for the new
grass gui and not Qt
and python ...)The only thing we need to provide is a data server and gui plugin for
ParaView3:
ParaView/Plugin HowTo - KitwarePublic
And when ParaView3 reaches a stable state and i have some spare time i'm
absolutely willingly to implement them!IMHO the data server and the reader/writer to the grass database
(grass data should be modified with Paraview3 and stored back into the grass
databaseif possible)
should be implemented in C++ for performance reasons. I would not use the
grass python wrapper
to get the data into a visualization system. The grass raster, voxel and
vector functions can be
accessed from C++ code directly.The data server should provide access to the grass database to read and write
raster, volume and vector data.
And ParaView3 should be extended with a nice little Qt gui to access the grass
data directly from the toolbar
(like Qgis). We don't need to touch the ParaView3 sources, we only need to
implement plugins.A screenshot of ParaView3 handling grass raster, volume and vector data
(exported with the *.out.vtk modules)
is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_
Screenshot_grass_data.pngJust my two cents ...
sorry for my English
Best regards
SoerenThanks
SydSören Gebbert wrote:
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/
which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2
for 3D graphics
I think these packages would be well worth having a close look at
especially MayaVi2 (Python wrapped VTK) for the 3D graphics.I would like to prefer a C++ grass data server + grass gui plugin for
paraview3
to visualize 3d data. This would a nice and fast solution.Best regards
Soerenthanks
Syd
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Sören Gebbert wrote:
And for now i'm not able to get even the new grass wxPython gui to run
on my debian etch system because of the dependencies.
FWIW, once wxPython 2.8.x stabilizes into Debian/testing, I hope to
backport the minimum requried packages* for GRASS GUI+1 to Etch. These
could be hosted either at backports.org, DebianGIS's Alioth repo, or my
google webspace.
[*] python-wxgtk2.8 python-wxtools wx2.8-i18n ??
Hamish
Hello Michael
On Sun, 22 Apr 2007, Michael Barton wrote:
Following up on this and the many other interesting posts to this thread...
I asked if anyone objected to having numpy or scipy (incluing numpy) as a
dependency for the new wxPython GUI. The response has been overwhelmingly in
favor, pointing out the many things possible with this kind of package.I just want to use it to make nicer plotting easier (e.g., for profiling and
histogramming) in the GUI, but obviously it has other uses. And of course,
there are a number of other even more sophisticated plotting/graphing
packages that also run under wxPython and scipy.
TBH I was being lazy and waiting for more information on what specifically it could be used for before giving an opinion... the names at least suggest they are primarily for numerical calculations etc. and not drawing graphics? I wonder do the parts of Pyplot you want to use even use anything
in NumPy? Obviously numerical calculations and that kind of stuff is best done in C in the GRASS libraries and modules to make it available also for command-line and scripting use. I think that's the main issue here, that having NumPy available doesn't result in the GUI having lots of
computational functionality that isn't available in the core of GRASS.
but just my opinion
Paul
Paul Kelly wrote:
> Following up on this and the many other interesting posts to this thread...
>
> I asked if anyone objected to having numpy or scipy (incluing numpy) as a
> dependency for the new wxPython GUI. The response has been overwhelmingly in
> favor, pointing out the many things possible with this kind of package.
>
> I just want to use it to make nicer plotting easier (e.g., for profiling and
> histogramming) in the GUI, but obviously it has other uses. And of course,
> there are a number of other even more sophisticated plotting/graphing
> packages that also run under wxPython and scipy.TBH I was being lazy and waiting for more information on what specifically
it could be used for before giving an opinion... the names at least
suggest they are primarily for numerical calculations etc. and not drawing
graphics? I wonder do the parts of Pyplot you want to use even use anything
in NumPy?
Looking at the source code, it's all basic stuff: primitive array
operations plus fabs, floor, ceil, log10, power, sqrt, minimum,
maximum.
The comment at the top of plot.py says:
This is a simple light weight plotting module that can be used with
Boa or easily integrated into your own wxPython application. The
emphasis is on small size and fast plotting for large data sets. It
has a reasonable number of features to do line and scatter graphs
easily as well as simple bar graphs.
Excluding the demo (which is built into the package), it's ~1500
(non-blank) lines of code.
AFAICT, an equivalent d.* module would be a decent day's work
(assuming that you knew what you wanted at the outset). The only real
advantage of PyPlot would be the ability to zoom/pan in real time.
[BTW, on the subject of perfomance: I've extended the PNG driver to
support writing 32-bpp BMP files. More significantly, if you set
GRASS_PNG_MAPPED=TRUE, it will immediately write out the file, then
mmap() for use as its framebuffer, so it doesn't have to explicitly
write the file after each command.]
--
Glynn Clements <glynn@gclements.plus.com>
Dear Michael,
Michael Barton schrieb:
It's great that we can export GRASS data to be used in high-end
multi-dimensional visualization platforms like Paraview and MayVi2. I've
used Paraview a bit. I wouldn't call it easy or intuitive, but it is quite
sophisticated and powerful--though not particularly fast in my experience.However, using any of these packages is not a replacement for NVIZ. NVIZ
will let a user quickly and seamlessly render 2, 2.5, 3, and 4 dimensional
data within a GRASS GIS session. This is a real bonus. And NVIZ does this
better than any other rendering engine within a GIS that I've seen. In this
sense, NVIZ has a different goal from Paraview and other dedicated
multidemensional rendering packages.So I hope that we can get NVIZ ported to wxPython and make it an even more
seamless part of the geospatial visualization tools for GRASS. Making
Good news. Nice to hear that. I hope you will redesign the gui, so it will be more intuitive.
I have had a look at the NVIZ code and was afraid that this construct is not maintainable.
Well, this is hopefully related to my very little knowledge of software design and C coding
with Tcl/Tk bindings.
tighter connections between GRASS and other, external visualization tools is
also a worthy plan--similar to the integration between GRASS and R. But
IMHO, we should not abandon NVIZ or something like it.
I guess you are right. An integrated 2.5d, 3d and 4d visualization tool is important.
The good thing is that ParaView is not only a visualization tool, it is
a preprocessing and analysis tool with 4d support and powerful threaded image processing.
Best regards
Soeren
Michael
On 4/22/07 4:31 PM, "Sören Gebbert" <soerengebbert@gmx.de> wrote:
Syd,
Syd Visser schrieb:
Soren
Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more
towards MayaVi2 although we use Paraview2.6 extensively but strictly as
a viewer.
We find MayaVi2 is also more open to user development thus easier to
extend.I'm developing with VTK and Qt since several years and have used ParaView1-2
for several years.
My experience with MayaVi is little, because the user interface was too
horrible.
IMHO ParaView3 is the better choice. It has a sophisticated but very
intuitive user interface and is developed by well known institutes and
kitware.
And they are doing a great job. ParaView is designed to visualize huge
datasets in parallel.MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new
dependencies (except wxPython).
And for now i'm not able to get even the new grass wxPython gui to run on my
debian etch system
because of the dependencies.
ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as
well as VTK.
(i still don't understand why wxWidgets and python was choosen for the new
grass gui and not Qt
and python ...)The only thing we need to provide is a data server and gui plugin for
ParaView3:
http://www.paraview.org/Wiki/Plugin_HowTo
And when ParaView3 reaches a stable state and i have some spare time i'm
absolutely willingly to implement them!IMHO the data server and the reader/writer to the grass database
(grass data should be modified with Paraview3 and stored back into the grass
database
should be implemented in C++ for performance reasons. I would not use the
grass python wrapper
to get the data into a visualization system. The grass raster, voxel and
vector functions can be
accessed from C++ code directly.The data server should provide access to the grass database to read and write
raster, volume and vector data.
And ParaView3 should be extended with a nice little Qt gui to access the grass
data directly from the toolbar
(like Qgis). We don't need to touch the ParaView3 sources, we only need to
implement plugins.A screenshot of ParaView3 handling grass raster, volume and vector data
(exported with the *.out.vtk modules)
is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_
Screenshot_grass_data.pngJust my two cents ...
sorry for my English
Best regards
SoerenThanks
SydSören Gebbert wrote:
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/
which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2
for 3D graphics
I think these packages would be well worth having a close look at
especially MayaVi2 (Python wrapped VTK) for the 3D graphics.I would like to prefer a C++ grass data server + grass gui plugin for
paraview3
to visualize 3d data. This would a nice and fast solution.Best regards
Soerenthanks
Syd__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Sorry! More in the text below.
Sören Gebbert schrieb:
Dear Michael,
Michael Barton schrieb:
It's great that we can export GRASS data to be used in high-end
multi-dimensional visualization platforms like Paraview and MayVi2. I've
used Paraview a bit. I wouldn't call it easy or intuitive, but it is quite
sophisticated and powerful--though not particularly fast in my experience.However, using any of these packages is not a replacement for NVIZ. NVIZ
will let a user quickly and seamlessly render 2, 2.5, 3, and 4 dimensional
data within a GRASS GIS session. This is a real bonus. And NVIZ does this
better than any other rendering engine within a GIS that I've seen. In this
sense, NVIZ has a different goal from Paraview and other dedicated
multidemensional rendering packages.So I hope that we can get NVIZ ported to wxPython and make it an even more
seamless part of the geospatial visualization tools for GRASS. MakingGood news. Nice to hear that. I hope you will redesign the gui, so it will be more intuitive.
I have had a look at the NVIZ code and was afraid that this construct is not maintainable.
Well, this is hopefully related to my very little knowledge of software design and C coding
with Tcl/Tk bindings.tighter connections between GRASS and other, external visualization tools is
also a worthy plan--similar to the integration between GRASS and R. But
IMHO, we should not abandon NVIZ or something like it.I guess you are right. An integrated 2.5d, 3d and 4d visualization tool is important.
The good thing is that ParaView is not only a visualization tool, it is
a preprocessing and analysis tool with 4d support and powerful threaded image processing.
I mean post-processing. Sorry for confusion.
Soeren
Best regards
SoerenMichael
On 4/22/07 4:31 PM, "Sören Gebbert" <soerengebbert@gmx.de> wrote:
Syd,
Syd Visser schrieb:
Soren
Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more
towards MayaVi2 although we use Paraview2.6 extensively but strictly as
a viewer.
We find MayaVi2 is also more open to user development thus easier to
extend.I'm developing with VTK and Qt since several years and have used ParaView1-2
for several years.
My experience with MayaVi is little, because the user interface was too
horrible.
IMHO ParaView3 is the better choice. It has a sophisticated but very
intuitive user interface and is developed by well known institutes and
kitware.
And they are doing a great job. ParaView is designed to visualize huge
datasets in parallel.MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new
dependencies (except wxPython).
And for now i'm not able to get even the new grass wxPython gui to run on my
debian etch system
because of the dependencies.
ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as
well as VTK.
(i still don't understand why wxWidgets and python was choosen for the new
grass gui and not Qt
and python ...)The only thing we need to provide is a data server and gui plugin for
ParaView3:
http://www.paraview.org/Wiki/Plugin_HowTo
And when ParaView3 reaches a stable state and i have some spare time i'm
absolutely willingly to implement them!IMHO the data server and the reader/writer to the grass database
(grass data should be modified with Paraview3 and stored back into the grass
database
should be implemented in C++ for performance reasons. I would not use the
grass python wrapper
to get the data into a visualization system. The grass raster, voxel and
vector functions can be
accessed from C++ code directly.The data server should provide access to the grass database to read and write
raster, volume and vector data.
And ParaView3 should be extended with a nice little Qt gui to access the grass
data directly from the toolbar
(like Qgis). We don't need to touch the ParaView3 sources, we only need to
implement plugins.A screenshot of ParaView3 handling grass raster, volume and vector data
(exported with the *.out.vtk modules)
is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_Screenshot_grass_data.png
Just my two cents ...
sorry for my English
Best regards
SoerenThanks
SydSören Gebbert wrote:
Hi,
Syd Visser schrieb:
We use enthought open source tool suite http://www.enthought.com/
which contains Numpy, SciPi and numerous other packages.
our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2
for 3D graphics
I think these packages would be well worth having a close look at
especially MayaVi2 (Python wrapped VTK) for the 3D graphics.I would like to prefer a C++ grass data server + grass gui plugin for
paraview3
to visualize 3d data. This would a nice and fast solution.Best regards
Soerenthanks
Syd__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree that integration is good, but I do not think NVIZ is
maintainable. I think a good and smooth link to an external 3d viewer
(call it Paraview or whatever). Why exactly this could not be a
replacement for nviz?
We cannot do everything within grass: the dev team is small compare to
the code base, and externalizing functions is the only way to make real
progress, in my view.
All the best.
pc
Michael Barton ha scritto:
So I hope that we can get NVIZ ported to wxPython and make it an even more
seamless part of the geospatial visualization tools for GRASS. Making
tighter connections between GRASS and other, external visualization tools is
also a worthy plan--similar to the integration between GRASS and R. But
IMHO, we should not abandon NVIZ or something like it.
- --
Paolo Cavallini
http://www.faunalia.it/pc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf
RFa1b0RgKp7BKmusclIn9k4=
=tFUj
-----END PGP SIGNATURE-----
Even though I am not a real developer, I just want to say that NVIZ
rocks! It could have some other features (like, create a view with a
oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but
it's easy to use, and produce some really nice outputs. I just
submitted a paper comparing ArcGis and GRASS for morphometric analysis
(guess who won?) and the 3D image we use was made in NVIZ, because
ArcScene doesn't even get close to the beauty of NVIZ 3D image.
Having a [lightweighted] n-D visualizer integrated in the system
really makes a difference.
just my 0.02
Carlos
On 4/23/07, Paolo Cavallini <cavallini@faunalia.it> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1I agree that integration is good, but I do not think NVIZ is
maintainable. I think a good and smooth link to an external 3d viewer
(call it Paraview or whatever). Why exactly this could not be a
replacement for nviz?
We cannot do everything within grass: the dev team is small compare to
the code base, and externalizing functions is the only way to make real
progress, in my view.
All the best.
pcMichael Barton ha scritto:
> So I hope that we can get NVIZ ported to wxPython and make it an even more
> seamless part of the geospatial visualization tools for GRASS. Making
> tighter connections between GRASS and other, external visualization tools is
> also a worthy plan--similar to the integration between GRASS and R. But
> IMHO, we should not abandon NVIZ or something like it.
- --
Paolo Cavallini
http://www.faunalia.it/pc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf
RFa1b0RgKp7BKmusclIn9k4=
=tFUj
-----END PGP SIGNATURE-----_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
Any website to ddownload this article/screenshots?
thanks,
Yann
On Monday 23 April 2007 21:07, Carlos "Guâno" Grohmann wrote:
Even though I am not a real developer, I just want to say that NVIZ
rocks! It could have some other features (like, create a view with a
oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but
it's easy to use, and produce some really nice outputs. I just
submitted a paper comparing ArcGis and GRASS for morphometric analysis
(guess who won?) and the 3D image we use was made in NVIZ, because
ArcScene doesn't even get close to the beauty of NVIZ 3D image.Having a [lightweighted] n-D visualizer integrated in the system
really makes a difference.just my 0.02
Carlos
On 4/23/07, Paolo Cavallini <cavallini@faunalia.it> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I agree that integration is good, but I do not think NVIZ is
> maintainable. I think a good and smooth link to an external 3d viewer
> (call it Paraview or whatever). Why exactly this could not be a
> replacement for nviz?
> We cannot do everything within grass: the dev team is small compare to
> the code base, and externalizing functions is the only way to make real
> progress, in my view.
> All the best.
> pc
>
> Michael Barton ha scritto:
> > So I hope that we can get NVIZ ported to wxPython and make it an even
> > more seamless part of the geospatial visualization tools for GRASS.
> > Making tighter connections between GRASS and other, external
> > visualization tools is also a worthy plan--similar to the integration
> > between GRASS and R. But IMHO, we should not abandon NVIZ or something
> > like it.
>
> - --
> Paolo Cavallini
> http://www.faunalia.it/pc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf
> RFa1b0RgKp7BKmusclIn9k4=
> =tFUj
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
--
Yann Chemin
Sainte-Anne d'Auray, France
Sorry, but not yet. The article has just been submitted, it will take
some time until I can show anything...
Thanks for the interest!
On 4/23/07, Yann <yann.chemin@gmail.com> wrote:
Any website to ddownload this article/screenshots?
thanks,
YannOn Monday 23 April 2007 21:07, Carlos "Guâno" Grohmann wrote:
> Even though I am not a real developer, I just want to say that NVIZ
> rocks! It could have some other features (like, create a view with a
> oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but
> it's easy to use, and produce some really nice outputs. I just
> submitted a paper comparing ArcGis and GRASS for morphometric analysis
> (guess who won?) and the 3D image we use was made in NVIZ, because
> ArcScene doesn't even get close to the beauty of NVIZ 3D image.
>
> Having a [lightweighted] n-D visualizer integrated in the system
> really makes a difference.
>
> just my 0.02
>
> Carlos
>
> On 4/23/07, Paolo Cavallini <cavallini@faunalia.it> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I agree that integration is good, but I do not think NVIZ is
> > maintainable. I think a good and smooth link to an external 3d viewer
> > (call it Paraview or whatever). Why exactly this could not be a
> > replacement for nviz?
> > We cannot do everything within grass: the dev team is small compare to
> > the code base, and externalizing functions is the only way to make real
> > progress, in my view.
> > All the best.
> > pc
> >
> > Michael Barton ha scritto:
> > > So I hope that we can get NVIZ ported to wxPython and make it an even
> > > more seamless part of the geospatial visualization tools for GRASS.
> > > Making tighter connections between GRASS and other, external
> > > visualization tools is also a worthy plan--similar to the integration
> > > between GRASS and R. But IMHO, we should not abandon NVIZ or something
> > > like it.
> >
> > - --
> > Paolo Cavallini
> > http://www.faunalia.it/pc
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf
> > RFa1b0RgKp7BKmusclIn9k4=
> > =tFUj
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev--
Yann Chemin
Sainte-Anne d'Auray, France_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
Could you post article references and figure screenshots?
This seems to be good material for some GRASS advocation and/or
ArcGIS bashing ...
Benjamin
Carlos "Guâno" Grohmann wrote:
Even though I am not a real developer, I just want to say that NVIZ
rocks! It could have some other features (like, create a view with a
oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but
it's easy to use, and produce some really nice outputs. I just
submitted a paper comparing ArcGis and GRASS for morphometric analysis
(guess who won?) and the 3D image we use was made in NVIZ, because
ArcScene doesn't even get close to the beauty of NVIZ 3D image.Having a [lightweighted] n-D visualizer integrated in the system
really makes a difference.just my 0.02
Carlos
On 4/23/07, Paolo Cavallini <cavallini@faunalia.it> wrote:
I agree that integration is good, but I do not think NVIZ is
maintainable. I think a good and smooth link to an external 3d viewer
(call it Paraview or whatever). Why exactly this could not be a
replacement for nviz?
We cannot do everything within grass: the dev team is small compare to
the code base, and externalizing functions is the only way to make real
progress, in my view.
All the best.
pcMichael Barton ha scritto:
So I hope that we can get NVIZ ported to wxPython and make it an
even more
seamless part of the geospatial visualization tools for GRASS. Making
tighter connections between GRASS and other, external visualizationtools is
also a worthy plan--similar to the integration between GRASS and R. But
IMHO, we should not abandon NVIZ or something like it.
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
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.
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.
Michael
On 4/23/07 6:46 AM, "Paolo Cavallini" <cavallini@faunalia.it> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1I agree that integration is good, but I do not think NVIZ is
maintainable. I think a good and smooth link to an external 3d viewer
(call it Paraview or whatever). Why exactly this could not be a
replacement for nviz?
We cannot do everything within grass: the dev team is small compare to
the code base, and externalizing functions is the only way to make real
progress, in my view.
All the best.
pcMichael Barton ha scritto:
So I hope that we can get NVIZ ported to wxPython and make it an even more
seamless part of the geospatial visualization tools for GRASS. Making
tighter connections between GRASS and other, external visualization tools is
also a worthy plan--similar to the integration between GRASS and R. But
IMHO, we should not abandon NVIZ or something like it.- --
Paolo Cavallini
Who we are | Faunalia
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf
RFa1b0RgKp7BKmusclIn9k4=
=tFUj
-----END PGP SIGNATURE-----
__________________________________________
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
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@gclements.plus.com>
On 4/23/07 11:59 AM, "Glynn Clements" <glynn@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