In the digest of the grass5 list that I just received, there are discussion
about the new r3.in.rast and r3.to.rast tools, rebuilding xganim, and
v.extrude.
The potential for expanding GIS to 3D for more than just nicely rendered
displays is very exciting--and not just to me--and sets GRASS apart from
other spatial analysis platforms.
For example, if we can store time series as grid3d volumes, xganim could be
replaced by an NVIZ-like utility that allows you to interactively view
slices down through such a volume (or diagonally or vertically--why not?),
kind of like the cutting planes in NVIZ.
Given that GIS data are inherently multidimensional, this holds much
promise. For example, we could better implement dynamic geospatial landscape
models or agent-based models given these new tools for manipulating and
displaying 3D/4D data.
IMHO, this is another reason why it is important to look for ways of better
integrating 2D and 3D in a future GRASS UI.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Sören Gebbert <soerengebbert@gmx.de>
Date: Wed, 23 Nov 2005 01:32:52 +0100
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] r3.mapcalc doesn't work, isosurfaces
Hi.
On Tuesday 22 November 2005 21:49, Joel Peter William Pitt wrote:
Okay, I got the latest CVS version and there are r3.to.rast and
r3.in.rast in there. They just don't get compiled by default because
they are not in the raster3d Makefile.
I've managed to get my timeseries into a r3 file. However things are a
bit buggy it seems.
Are there bugs in r3.in.rast? And if yes, what kind of bugs?
If there are bugs, i will try to fix them.
I know that in r3.to.rast the NULL handling was wrong, but
that was fixed some days ago in the CVS.
Is the following supposed to work for volumes?
r3.mapcalc "test2=test"
At the moment any r3.mapcalc operations involving another r3 file seem
to result in a file full of nan's...
$ r3.info -r test
min=1.000000
max=1.000000
$ r3.info -r test2
min=nan
max=nan
I have no problems.
Mapset <data> in Location <slovakia3d>GRASS 6.1.cvs > r3.in.rast
input=dem500@PERMANENT output=dem3d
Open raster map dem500@PERMANENT
Open raster map dem500
Open raster map dem500
Open raster map dem500
Open raster map dem500
Open raster map dem500
Creating 3D raster map
100%
100%
100%
100%
100%
100%
Mapset <data> in Location <slovakia3d>GRASS 6.1.cvs > r3.info -r dem3d
min=0.000000
max=2230.092041
Mapset <data> in Location <slovakia3d>GRASS 6.1.cvs > r3.mapcalc "test =
dem3d"
100%
Mapset <data> in Location <slovakia3d>GRASS 6.1.cvs > r3.info -r test
min=0.000000
max=2230.092041
Mapset <data> in Location <slovakia3d>GRASS 6.1.cvs >
What kind of maps (floar or double) and projection are you using? Are you
using a mask?
I know that there are some problems with mask support in 3d maps.
Also, is the interpolation done by NVIZ on volumes able to handle
boolean values? Imagine a pyramid of value 1 surrounded by zero/null,
and occasional occurences of of cells equal to 1 outside of this
pyramid. I set a threshold of 1.0 on the volume in NVIZ but nothing
appears.... any ideas?
nope.
Thanks,
Joel
Helena Mitasova wrote:
I will leave others to answer your NULL question (just another reason
to start working on new raster map storage format for GRASS7).
Regarding using 3d rasters for storing timeseries we need it badly for
the simwe programs and I tried to convert an output of simulation to
3d raster using
Soeren's r3.in.rast (I noticed it is not in GRASS CVS? - but you can
get it from here:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/) and then
convert back using r3.to.rast for viewing, analysis etc.
It works and if nothing else storing time series as 3d raster makes
mapsets with multiple simulation runs much more manageable.
It would be great if you could test whether it also takes much less
space and how it would work with 3d mask.
If it is indeed more space efficient, it may be worth to write few
modules to work with such timeseries (e.g. extend xganim and
r.out.mpeg to work with it, etc.).
I would then make it an option to write the timeseries output of simwe
programs either as 2d rasters or a 3d single file.
Please, let me know whatever you find useful regarding to handling of
timeseries in GRASS, it will help our work too,
Helena
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joel Pitt, Room B534
Bio-Protection & Ecology Division
PO Box 84
Lincoln University 8150
New Zealand