[GRASS-user] Re: grass-user Digest, Vol 46, Issue 35

GRASS GRASS user
1

On Feb 12, 2010, at 6:29 PM, grass-user-request@lists.osgeo.org wrote:

Date: Fri, 12 Feb 2010 09:52:54 -0800 (PST)
From: Rich Shepard <rshepard@appl-ecosys.com>
Subject: [GRASS-user] Two General Questions
To: grass-users@lists.osgeo.org
Message-ID: <alpine.LNX.2.00.1002120944470.5184@salmo.appl-ecosys.com>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

  1) Can GRASS work with TINs for elevation determinations? I've not seen
anything about it, yet I've read that it has advantages over raster-based
DEMs for some purposes and wonder if there are any plans to accommodate this
data structure.

TIN's are a way of creating an elevation surface using vector polygons rather than rasters. When computers had slow processors, primitive displays, limited RAM, and limited disk space, they were a way of getting elevation in a way that optimized hardware limitations. They did so at a cost of resolution and simplicity of analysis/processing. They have also been used for 2.5D visualization, again to overcome hardware/software limitations.

GRASS can work with TIN's somewhat, creating them in v.delaunay and displaying them in nviz. However, it manages raster grids VERY fast and the 2.5 - 3.5D display in NVIZ is extraordinarily fast, using OpenGL. So IMHO, there is not much point to the hassle of TINs

  2) Is there documentation on how to drape a bit-mapped image (specifically
from Google maps) over a shaded relief map? I know the downloaded .ps would
need to be converted to a bit-map format using 'convert', then georectified
with afine transformations, but it would certainly allow for impressive
presentations when the intended audience is non-technical. For my work,
impressive visuals is critical to accepting technical results.

This is built into the GUI. Bring up a shaded map layer and drape anything over any base map.

For display outside the GUI there is d.shaded.map -- which is a script that calls d.his to do this.

Michael

2

On Fri, 12 Feb 2010, Michael Barton wrote:

TIN's are a way of creating an elevation surface using vector polygons
rather than rasters. When computers had slow processors, primitive
displays, limited RAM, and limited disk space, they were a way of getting
elevation in a way that optimized hardware limitations. They did so at a
cost of resolution and simplicity of analysis/processing. They have also
been used for 2.5D visualization, again to overcome hardware/software
limitations.

Michael,

   My understanding, which might well be totally incorrect, is that TINs are
better at representing the sloping surface in hilly terrain and, therefore,
provide better hydrological modeling. The differences might very well be
totally insignificant between rainfall-runoff models based on cells and
TINs, except when the basin is a that of a headwater originating stream
reach.

This is built into the GUI. Bring up a shaded map layer and drape anything
over any base map.

   OK. I'll give that a try.

For display outside the GUI there is d.shaded.map -- which is a script
that calls d.his to do this.

   Good to know. Thanks.

Rich

3

Michael Barton wrote:

TIN's are a way of creating an elevation surface using vector polygons
rather than rasters. When computers had slow processors, primitive
displays, limited RAM, and limited disk space, they were a way of getting
elevation in a way that optimized hardware limitations. They did so at a
cost of resolution and simplicity of analysis/processing.

I'm curious why you say TINs are used at the "cost of resolution"? What if I
have a surface sampled by a dense irregularly spaced point data set, e.g. a
lidar point cloud. If I create a TIN using a delaunay triangulation of those
points the resulting model will exactly pass through all of the original
data points with linear interpolations between. As a result it resolves all
of the detail in the original data. In contrast, if I use a raster map to
model the surface it will inevitably lead to some degree of aggregation as a
function of the interpolation method I choose. The same is true if I want to
incorporate linear features such as breaklines into the model. Of course,
the question of which type of model is more useful for a given application
is entirely separate.

Best,

--
Jed Frechette

University of New Mexico Lidar Lab
www.unm.edu/~lidar
--
View this message in context: http://n2.nabble.com/Re-grass-user-Digest-Vol-46-Issue-35-tp4564699p4567229.html
Sent from the Grass - Users mailing list archive at Nabble.com.