[GRASS-SVN] r36476 - grass/branches/develbranch_6/vector/lidar/v.surf.bspline

svn_grass at osgeo.org svn_grass at osgeo.org
Wed Mar 25 03:14:38 EDT 2009 

Author: neteler
Date: 2009-03-25 03:14:37 -0400 (Wed, 25 Mar 2009)
New Revision: 36476

Modified:
   grass/branches/develbranch_6/vector/lidar/v.surf.bspline/description.html
Log:
long lines broken; cosmetics

Modified: grass/branches/develbranch_6/vector/lidar/v.surf.bspline/description.html
===================================================================
--- grass/branches/develbranch_6/vector/lidar/v.surf.bspline/description.html	2009-03-25 06:51:51 UTC (rev 36475)
+++ grass/branches/develbranch_6/vector/lidar/v.surf.bspline/description.html	2009-03-25 07:14:37 UTC (rev 36476)
@@ -6,96 +6,178 @@
 Optionally, a "sparse point" vector map can be input specify vector points
 output.
 <br> <br>
-From a theoretical perspective, the interpolating procedure takes place in two parts: the first is an estimate of the linear coefficients of a spline function is derived from the observation points using a least squares regression; the second is the computation of the interpolated surface (or interpolated vector points). As used here, the splines are 2D piece-wise non-zero polynomial functions calculated within a limited, 2D area. The length of each spline step is defined by <b><i>sie</i></b> for the east-west direction and <b><i>sin</i></b> for the north-south direction. For optimum performance, the length of spline step should be no less than the distance between observation points. Each vector point observation is modeled as a linear function of the non-zero splines in the area around the observation. The least squares regression predicts the the coefficients of these linear functions. Regularization, avoids the need to have one one observation and one coefficient for each spline (in order to avoid instability). 
-<br><br>
-With regularly distributed data points, a spline step corresponding to the maximum distance between two points in both the east and north directions is sufficient. But often data points are not regularly distributed and require statistial regularization or estimation. In such cases, v.surf.bspline will attempt to minimize the gradient of bilinear splines or the curvature of bicubic splines in areas lacking point observations. As a general rule, spline step length should be greater than the mean distance between observation points (twice the distance between points is a good starting point). Separate east-west and north-south spline step length arguments allows the user to account for some degree of anisotropy in the distribution of observation points. Short spline step lengths--especially spline step lengths that are less than the distance between observation points--can greatly increase processing time.
-<br><br>
-Moreover, the maximum number of splines for each direction at each time is fixed, regardless of the spline step length. As the total number of splines used increases (i.e., with small spline step lengths), the region is automatically into subregions for interpolation. Each subregion can contain no more than 150x150 splines. To avoid subregion boundary problems, subregions are created to partially overlap each other. A weighted mean of observations, based on point locations, is calculated within each subregion. 
-<br><br>
-The Tykhonov regularization parameter ("<b><i>lambda_i</i></b>") acts to smooth the interpolation. With a small <b><i>lambda_i</i></b>, the interpolated surface closely follows observation points; a larger value will produce a smoother interpolation.
-<br><br>
-The input can be a 2D pr 3D vector points map. If "<b><i>layer =</i></b>" 0 the z-value of a 3D map is used for interpolation. If layer > 0, the user must specify an attribute column to used for interpolation using the "<b><i>column=</i></b>" argument (2D or 3D map). 
-<br><br>
-v.surf.bspline can produce a raster OR a vector output (NOT simultaneously). However, a vector output cannot be obtained using the default GRASS dbf driver. 
-<br><br>
-If output is a vector points map and a "<b><i>sparse=</i></b>" vector points map is not specified, the output vector map will contain points at the same locations as observation points in the input map, but the values of the output points are interpolated values. If a "<b><i>sparse=</i></b>" vector points map is specified, the output vector map will contain points at the same locations as the sparse vector map points, and values will be those of the interpolated raster surface at those points.
-<br><br>
-A cross validation "leave-one-out" analysis is available to help to determine the optimal <b><i>lambda_i</i></b> value that produces an interpolation that best fits the original observation data. The more points used for cross-validation, the longer the time needed for computation. Empirical testing indicates a threshold of a maximum of 100 points is recommended. The cross-validation output reports <i>mean</i> and <i>rms</i> of the residuals from the true point value and the estimated from the interpolation for a fixed series of <b><i>lambda_i</i></b> values. No vector nor raster output will be created when cross-validation is selected. 
-<br><br>
-A raster output map ("<b><i>raster=</i></b>") of more than 2000x2000 (4 mill) cells is not allowed. If an output map would exceed this size, an error message is generated.
+From a theoretical perspective, the interpolating procedure takes place in two
+parts: the first is an estimate of the linear coefficients of a spline function
+is derived from the observation points using a least squares regression; the
+second is the computation of the interpolated surface (or interpolated vector
+points). As used here, the splines are 2D piece-wise non-zero polynomial
+functions calculated within a limited, 2D area. The length of each spline step
+is defined by <b><i>sie</i></b> for the east-west direction and
+<b><i>sin</i></b> for the north-south direction. For optimum performance, the
+length of spline step should be no less than the distance between observation
+points. Each vector point observation is modeled as a linear function of the
+non-zero splines in the area around the observation. The least squares
+regression predicts the the coefficients of these linear functions.
+Regularization, avoids the need to have one one observation and one coefficient
+for each spline (in order to avoid instability). 
 
+<p>
+With regularly distributed data points, a spline step corresponding to the
+maximum distance between two points in both the east and north directions is
+sufficient. But often data points are not regularly distributed and require
+statistial regularization or estimation. In such cases, v.surf.bspline will
+attempt to minimize the gradient of bilinear splines or the curvature of bicubic
+splines in areas lacking point observations. As a general rule, spline step
+length should be greater than the mean distance between observation points
+(twice the distance between points is a good starting point). Separate east-west
+and north-south spline step length arguments allows the user to account for some
+degree of anisotropy in the distribution of observation points. Short spline
+step lengths--especially spline step lengths that are less than the distance
+between observation points--can greatly increase processing time.
+
+<p>
+Moreover, the maximum number of splines for each direction at each time is
+fixed, regardless of the spline step length. As the total number of splines used
+increases (i.e., with small spline step lengths), the region is automatically
+into subregions for interpolation. Each subregion can contain no more than
+150x150 splines. To avoid subregion boundary problems, subregions are created to
+partially overlap each other. A weighted mean of observations, based on point
+locations, is calculated within each subregion. 
+
+<p>
+The Tykhonov regularization parameter ("<b><i>lambda_i</i></b>") acts to smooth
+the interpolation. With a small <b><i>lambda_i</i></b>, the interpolated surface
+closely follows observation points; a larger value will produce a smoother
+interpolation.
+
+<p>
+The input can be a 2D pr 3D vector points map. If "<b><i>layer =</i></b>" 0 the
+z-value of a 3D map is used for interpolation. If layer > 0, the user must
+specify an attribute column to used for interpolation using the
+"<b><i>column=</i></b>" argument (2D or 3D map). 
+
+<p>
+v.surf.bspline can produce a raster OR a vector output (NOT simultaneously).
+However, a vector output cannot be obtained using the default GRASS DBF driver. 
+
+<p>
+If output is a vector points map and a "<b><i>sparse=</i></b>" vector points map
+is not specified, the output vector map will contain points at the same
+locations as observation points in the input map, but the values of the output
+points are interpolated values. If a "<b><i>sparse=</i></b>" vector points map
+is specified, the output vector map will contain points at the same locations as
+the sparse vector map points, and values will be those of the interpolated
+raster surface at those points.
+
+<p>
+A cross validation "leave-one-out" analysis is available to help to determine
+the optimal <b><i>lambda_i</i></b> value that produces an interpolation that
+best fits the original observation data. The more points used for
+cross-validation, the longer the time needed for computation. Empirical testing
+indicates a threshold of a maximum of 100 points is recommended. The
+cross-validation output reports <i>mean</i> and <i>rms</i> of the residuals from
+the true point value and the estimated from the interpolation for a fixed series
+of <b><i>lambda_i</i></b> values. No vector nor raster output will be created
+when cross-validation is selected. 
+
+<p>
+A raster output map ("<b><i>raster=</i></b>") of more than 2000x2000 (4 mill)
+cells is not allowed. If an output map would exceed this size, an error message
+is generated.
+
+
 <h2>EXAMPLES</h2>
 
 <h4>Basic interpolation</h4>
 
-<div class="code"><pre>v.surf.bspline input=point_vector output=interpolate_surface type=bicubic
+<div class="code"><pre>
+v.surf.bspline input=point_vector output=interpolate_surface type=bicubic
 </pre></div>
 
-A bicubic spline interpolation will be done and a vector points map with estimated (i.e., interpolated) values will be created. 
+A bicubic spline interpolation will be done and a vector points map with estimated
+(i.e., interpolated) values will be created. 
 
 <h4>Basic interpolation and raster output with a longer spline step</h4>
 
-<div class="code"><pre>v.surf.bspline input=point_vector raster=interpolate_surface sie=25 sin=25
+<div class="code"><pre>
+v.surf.bspline input=point_vector raster=interpolate_surface sie=25 sin=25
 </pre></div>
 
-A bilinear spline interpolation will be done with a spline step length of 25 map units. An interpolated raster map will be created at the current region resolution.
+A bilinear spline interpolation will be done with a spline step length of 25 map
+units. An interpolated raster map will be created at the current region resolution.
 
 <h4>Estimation of <b><i>lambda_i</i></b> parameter with a cross validation proccess</h4>
 
-<div class="code"><pre>v.surf.bspline -c input=point_vector 
+<div class="code"><pre>
+v.surf.bspline -c input=point_vector 
 </pre></div>
 
 <h4>Estimation on sparse points</h4>
 
-<div class="code"><pre>v.surf.bspline input=point_vector sparse=sparse_points output=interpolate_surface
+<div class="code"><pre>
+v.surf.bspline input=point_vector sparse=sparse_points output=interpolate_surface
 </pre></div>
 
 An output map of vector points will be created, corresponding to the sparse vector map, with interpolated values.
 
 <h4>Using attribute values instead Z-coordinates</h4>
-<div class="code"><pre>v.surf.bspline input=point_vector raster=interpolate_surface layer=1 column=attrib_column
+<div class="code"><pre>
+v.surf.bspline input=point_vector raster=interpolate_surface layer=1 column=attrib_column
 </pre></div>
 
-The interpolation will be done using the values in attrib_column, in the table associated with layer 1.
+The interpolation will be done using the values in attrib_column, in the
+table associated with layer 1.
 
 <h2>BUGS</h2>
 Known issues:
-<br><br>
-In order to avoid RAM memory problems, an auxiliary table is needed for recording some intermediate calculations. This requires the "<b>GROUP BY</b>" SQL function is used, which is not supported by the "<b>dbf</b>" driver. For this reason, vector map output "<b><i>output=</i></b>" is not permitted with the dbf driver. There are no problems with the raster map output from the dbf driver.
-<br><br>
-At this time, sparse vector input ("<b><i>sparse=</i></b>") can only be used with interpolation from 3D vector z-coordinates.
-<br><br>
+<p>
+In order to avoid RAM memory problems, an auxiliary table is needed for
+recording some intermediate calculations. This requires the "<b>GROUP BY</b>"
+SQL function is used, which is not supported by the "<b>dbf</b>" driver. For
+this reason, vector map output "<b><i>output=</i></b>" is not permitted with the
+DBF driver. There are no problems with the raster map output from the DBF
+driver.
 
+<p>
+At this time, sparse vector input ("<b><i>sparse=</i></b>") can only be used
+with interpolation from 3D vector z-coordinates (<a href="http://trac.osgeo.org/grass/ticket/96">trac #96</a>).
+<p>
 
+
 <h2>SEE ALSO</h2>
-<em><a href="http://grass.osgeo.org/grass64/manuals/html64_user/v.surf.rst.html">v.surf.rst</a></em>
 
+<em><a
+href="http://grass.osgeo.org/grass64/manuals/html64_user/v.surf.idw.html">v.surf.idw</a>,
+<a
+href="http://grass.osgeo.org/grass64/manuals/html64_user/v.surf.rst.html">v.surf.rst</a></em>
+
 <h2>AUTHORS</h2>
+
 Original version in GRASS 5.4: (s.bspline.reg)
 <br>
 Maria Antonia Brovelli, Massimiliano Cannata, Ulisse Longoni, Mirko Reguzzoni
-<br><br>
+<p>
 Update for GRASS 6.X and improvements:
 <br>
 Roberto Antolin
 
 <h2>REFERENCES</h2>
+
 Brovelli M. A., Cannata M., and Longoni U.M., 2004, LIDAR Data
 Filtering and DTM Interpolation Within GRASS, Transactions in GIS,
 April 2004, vol. 8, iss. 2, pp. 155-174(20), Blackwell Publishing Ltd
-<br>
-<br>Brovelli M. A. and Cannata M., 2004, Digital Terrain model
+<p>
+Brovelli M. A. and Cannata M., 2004, Digital Terrain model
 reconstruction in urban areas from airborne laser scanning data: the
 method and an example for Pavia (Northern Italy). Computers and
 Geosciences 30, pp.325-331
-<br>
-<br>Brovelli M. A e Longoni U.M., 2003, Software per il filtraggio di
+<p>
+Brovelli M. A e Longoni U.M., 2003, Software per il filtraggio di
 dati LIDAR, Rivista dell'Agenzia del Territorio, n. 3-2003, pp. 11-22
 (ISSN 1593-2192)
-<br>
-<br>
-Antolin R. and Brovelli M.A., 2007, LiDAR data Filtering with GRASS GIS for the Determination of Digital Terrain Models. 
-Proceedings of Jornadas de SIG Libre, Girona, Espa&ntilde;a. CD ISBN:
-978-84-690-3886-9 <br>
+<p>
+Antolin R. and Brovelli M.A., 2007, LiDAR data Filtering with GRASS GIS for the 
+Determination of Digital Terrain Models. Proceedings of Jornadas de SIG Libre,
+Girona, Espa&ntilde;a. CD ISBN: 978-84-690-3886-9 <br>
 
 <p><i>Last changed: $Date$</i>

More information about the grass-commit mailing list