Christian Ferreira wrote:
Actually, here I have a very strange thing...
If I run g.list rast3d, I can list my interpoled volume.
But if I try to run "r3.info ctd_volume2" in the
command line I get a messagetelling "ERROR: Raster map <ctd_volume2> not
found", but if I use the GUI for
r3.info is possible to read the
file (like above).The same happens if I try start nviz with:
"nviz bathy volume=ctd_volume2"
no idea.
Aham. So, this means that v.vol.rst is not supposed to be used with
Lat-Long?
no idea, I'm just speculating based on the fact that lat/lon adds a lot
of complication and the coder would have to had specifically written
in special support for it.
If yes, I will definitely quit this Lat-Long location and
go to UTM.
try both, see which way works best....
Well, after trying the whole Friday with nearlly no
results, I'm quite convinced that v.vol.rst is not dumb.
I meant that in the sense of it may not be lat/lon aware, not at all
that it was a stupid program.
Here is a try adjusting res3 to 0.000278 (30m), zmult to
the same number and dmin to 0.001http://picasaweb.google.com/chris.for.lists/Map#5334573425418213906
volume seems 90deg roated?!
Hamish:
actually the thing that I worry about there is not the x,y with z
using different units (easily fixed by reprojecting to a
planimetric projection), it is that all of your data points are
essentially in a single straight line, and what effect that has on
the 3D algorithm?
Christian:
As long I'm capable to produce a 2D slice along the transect/volume
to show the data, the rest would not matter for the moment.But I understand that interpolation algorithm is having a
hard time when trying to interpolate the cells away from
the transect.
again, I'm no expert at all with the module, just guessing.
certainly all interpolation modules will have problems extrapolating
through unconstrained boundaries to some extent.
This was a test... the best is probably how you are saying
below...
it is a good test to do..
have you done the same thing with UTM before had had good results?
Well, is not better (or possible) to set in GRASS a
temporary region so thin (in the N-S axis) to create this 2D slice?
sure, but I meant it was a 2D problem (x vs z) and you could fool the
GIS into using its 2D x,y tools to solve the x,z problem then rotate
the cells back to the correct orientation.
and also maybe some r3.out.vtk stuff with Paraview or Vis5D?
I'm trying to simply do all using GRASS... maybe is not
the best choice.
as good as any, better than most. 
just different tools for the job to explore.
Hamish
