[GRASS5] r3.mapcalc doesn't work, isosurfaces

[Michael Barton]

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 at gmx.de>
> Date: Wed, 23 Nov 2005 01:32:52 +0100
> To: <grass5 at 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 at PERMANENT output=dem3d
> Open raster map dem500 at 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
>> 
>