Hi Hamish,<br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">stepping back a bit from the 3D, does any one have a comment about<br>

the appropriateness of using v.surf.rst in lat/lon locations?<br>
<div class="im"></div></blockquote><div class="im"><br>So, I have multibeam data covering the coast of Ecuador and Peru. <br>And Since this data was in Lat-Long, as well the stations lists, I just tried <br>to use the same format.<br>
<br>Personally, I try to use Lat-Long because my &quot;working areas&quot; are normally<br>big. <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">did you get a result? (be a &quot;try it and find out&quot; experimentalist :)<br>
<div class="im"></div></blockquote><div class="im"><br>Apparently I have results see bellow, and I see it on nviz.<br><br><a href="http://picasaweb.google.com/chris.for.lists/Map#5334573425418213906">http://picasaweb.google.com/chris.for.lists/Map#5334573425418213906</a><br>
<br>+----------------------------------------------------------------------------+<br> | Layer:    cdt_volume2@PERMANENT          Date: Mon May 11 16:06:29 2009    |<br> | Mapset:   PERMANENT                      Login of Creator: christian       |<br>
 | Location: Transect11                                                       |<br> | DataBase: /Users/christian/Work/M77/GRASS                                  |<br> | Title:     ( cdt_volume2 )                                                 |<br>
 | Timestamp: none                                                            |<br> |----------------------------------------------------------------------------|<br> |                                                                            |<br>
 |   Type of Map:  3d cell              Number of Categories: 0               |<br> |   Data Type:    double                                                     |<br> |   Rows:         359                                                        |<br>
 |   Columns:      3835                                                       |<br> |   Depths:       10                                                         |<br> |   Total Cells:  13767650                                                   |<br>
 |        Projection: Latitude-Longitude (zone 0)                             |<br> |            N: 10:57:00.288311S    S:     11:03S   Res: 0:00:01.001982      |<br> |            E: 77:45:13.757688W    W:  78:49:12W   Res: 0:00:01.000845      |<br>
 |            T:          0    B:      -2200   Res:   220                     |<br> |   Range of data:   min = 2.56193161 max = 12.80138111                      |<br> |                                                                            |<br>
 |   Data Source:                                                             |<br> |                                                                            |<br> |                                                                            |<br>
 |                                                                            |<br> |   Data Description:                                                        |<br> |    generated by v.vol.rst                                                  |<br>
 |                                                                            |<br> |   Comments:                                                                |<br> |    v.vol.rst input=&quot;ctd_3d&quot; cellinp=&quot;bathy&quot; wcolumn=&quot;temperatur&quot; tensio\   |<br>
 |    n=40. smooth=0.1 segmax=100 npmin=200 dmin=0.01 wmult=1.0 zmult=0.00\   |<br> |    0278 elev=&quot;cdt_volume2&quot;                                                 |<br> |                                                                            |<br>
 +----------------------------------------------------------------------------+<br><br>Actually, here I have a very strange thing... <br><br>If I run g.list rast3d, I can list my interpoled volume.<br><br>But if I try to run &quot;<a href="http://r3.info">r3.info</a> ctd_volume2&quot; in the command line I get a message <br>
telling &quot;ERROR: Raster map &lt;ctd_volume2&gt; not found&quot;, but if I use the GUI for<br><a href="http://r3.info">r3.info</a> is possible to read the file (like above). <br><br>The same happens if I try start nviz with:<br>
<br>&quot;nviz bathy volume=ctd_volume2&quot;<br><br>So, here is something wrong, because I&#39;m able to manipulate the file just using the GUI... <br>I don&#39;t unterstand what? Maybe a bug?<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">so res ~ 30m?<br>
<div class="im"></div></blockquote><div class="im"><br>Yes! <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">it is approx 1 degree wide, and even though it is on the edge of UTM 18<br>
you probably can get away with reprojecting half way into the next zone<br>
with acceptable distortion. else just set up a custom transverse mercator<br>
with a lon_0 of 78W instead of 75W to work in.<br>
<br>
as you have already guessed, giving x,y,z all using the same units<br>
removes a lot of problems.<br>
<div class="im"></div></blockquote><div><br>Aham. So, this means that v.vol.rst is not supposed to be used with Lat-Long?<br><br>If yes, I will definitely quit this Lat-Long location and go to UTM.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don&#39;t know, I expect it doesn&#39;t know about lat/lon units so it may<br>
consider depths to be in degrees too. but maybe that&#39;s ok -- once it<br>
is stretched back to meters the effect will be to induce a barrier to<br>
strong vertical mixing, versus the relative ease of horizontal mixing,<br>
which is in fact somewhat realistic. (at least it&#39;s wrong in the right<br>
direction)<br>
<br>
NVIZ does know to scale lat/lon maps back to meters for 2.5D raster<br>
maps*, probably it scales 3D volumes too?<br>
<br>
[*] that still requires some heavy refinement though<br>
<div class="im"></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don&#39;t know, but I&#39;d guess it is &quot;dumb&quot;. Also I don&#39;t know if dmin<br>
is considered in the voxel cube or just in horizontal slices?<br>
<br>
Something you might try is to divide the depths by 1852*60 (approx<br>
meters in a deg lat) to convert the depths into degree units, but<br>
really reprojecting into UTM or so would be my first try. you are<br>
somewhat lucky that you are working near the equator.<br>
<div class="im"></div></blockquote><div><br>Well, after trying the whole Friday with nearlly no results, I&#39;m quite convinced <br>that v.vol.rst is not dumb.<br>
<br>
And, I was not able to set very well &quot;dmin&quot;.So, the results were strange.<br>
<br>
Here is a try adjusting res3 to 0.000278 (30m), zmult to the same number and dmin to 0.001<br><br><a href="http://picasaweb.google.com/chris.for.lists/Map#5334573425418213906">http://picasaweb.google.com/chris.for.lists/Map#5334573425418213906</a><br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">actually the thing that I worry about there is not the x,y with z using<br>
different units (easily fixed by reprojecting to a planimetric<br>
projection), it is that all of your data points are essentially in a<br>
single straight line, and what effect that has on the 3D algorithm?<br>
<div class="im"></div></blockquote><div><br>As long I&#39;m capable to produce a 2D slice along the transect/volume <br>to show the data, the rest would not matter for the moment.<br><br>But I understand that interpolation algorithm is having a hard time when trying to<br>
interpolate the cells away from the transect.<br><br>This was a test... the best is probably how you are saying below... <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>perhaps remake your axes as distance-along-transect vs. depth? then<br>
treat distance as the x axis and depth as the y axis and make a simple<br>
2D interpolation? (classic matlab contourf(), shading flat or masked<br>
v.surf.rst) then somehow rotate it to be a 1 cell wide 3D raster* to<br>
throw up?<br>
<br>
[*] I haven&#39;t (yet) written a r3.{in|out}.mat but I suppose it would<br>
not be too hard for you to write a little script to create a single<br>
slice to import with r3.in.ascii (see the help page examples) to rotate<br>
the 2D slice to a vertical one?<br>
</blockquote><div><br>Well, is not better (or possible) to set in GRASS a temporary region so thin <br>(in the N-S axis) to create this 2D slice?<br><br>Otherwise, I will simply do it like you said before... creating a 1 cell wide 3D raster.<br>
<br>PS: I using for this tests GRASS in a Macbook/Intel on Mac OS X 10.5, and using<br>the binaries from <a href="http://www.kyngchaos.com/software:grass/">http://www.kyngchaos.com/software:grass/</a><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
check out Helena&#39;s Chesapeake Bay interpolations:<br>
<a href="http://grass.osgeo.org/screenshots/viz.php" target="_blank">http://grass.osgeo.org/screenshots/viz.php</a>  (near the end)<br>
<a href="http://skagit.meas.ncsu.edu/%7Ehelena/gmslab/viz/ches.html" target="_blank">http://skagit.meas.ncsu.edu/~helena/gmslab/viz/ches.html</a><br>
<br>
and also maybe some r3.out.vtk stuff with Paraview or Vis5D?<br>
<font color="#888888"></font></blockquote><div><br>I&#39;m trying to simply do all using GRASS... maybe is not the best choice.<br><br>Regards,<br>Chris<br></div></div><br>-- <br>Christian Ferreira<br>Oceanographer<br>IFM-GEOMAR Leibniz-Institute of Marine Sciences<br>
Kiel - Germany<br><br>Poseidon Linux team<br><a href="http://www.poseidonlinux.org">http://www.poseidonlinux.org</a><br>