~ubuntu-branches/ubuntu/vivid/grass/vivid-proposed

« back to all changes in this revision

Viewing changes to vector/lidar/v.surf.bspline/description.html

  • Committer: Package Import Robot
  • Author(s): Bas Couwenberg
  • Date: 2015-02-20 23:12:08 UTC
  • mfrom: (8.2.6 experimental)
  • Revision ID: package-import@ubuntu.com-20150220231208-1u6qvqm84v430b10
Tags: 7.0.0-1~exp1
* New upstream release.
* Update python-ctypes-ternary.patch to use if/else instead of and/or.
* Drop check4dev patch, rely on upstream check.
* Add build dependency on libpq-dev to grass-dev for libpq-fe.h.
* Drop patches applied upstream, refresh remaining patches.
* Update symlinks for images switched from jpg to png.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
<h2>DESCRIPTION</h2>
2
 
<em>v.surf.bspline</em> performs a bilinear/bicubic spline interpolation with
3
 
Tykhonov regularization. The input is a 2D or 3D vector points map. Values to
4
 
interpolate can be the z values of 3D points or the values in a user-specified
5
 
attribue column in a 2D or 3D map. Output can be a raster or vector map.
6
 
Optionally, a "sparse point" vector map can be input which indicates the
7
 
location of <b><i>output</i></b> vector points.
8
 
<p>
9
 
From a theoretical perspective, the interpolating procedure takes place in two
10
 
parts: the first is an estimate of the linear coefficients of a spline function
11
 
is derived from the observation points using a least squares regression; the
12
 
second is the computation of the interpolated surface (or interpolated vector
13
 
points). As used here, the splines are 2D piece-wise non-zero polynomial
14
 
functions calculated within a limited, 2D area. The length of each spline step
15
 
is defined by <b><i>sie</i></b> for the east-west direction and
16
 
<b><i>sin</i></b> for the north-south direction. For optimum performance, the
17
 
length of spline step should be no less than the distance between observation
18
 
points. Each vector point observation is modeled as a linear function of the
19
 
non-zero splines in the area around the observation. The least squares
20
 
regression predicts the the coefficients of these linear functions.
21
 
Regularization, avoids the need to have one one observation and one coefficient
22
 
for each spline (in order to avoid instability). 
23
 
 
24
 
<p>
25
 
With regularly distributed data points, a spline step corresponding to the
26
 
maximum distance between two points in both the east and north directions is
27
 
sufficient. But often data points are not regularly distributed and require
28
 
statistial regularization or estimation. In such cases, v.surf.bspline will
29
 
attempt to minimize the gradient of bilinear splines or the curvature of bicubic
30
 
splines in areas lacking point observations. As a general rule, spline step
31
 
length should be greater than the mean distance between observation points
32
 
(twice the distance between points is a good starting point). Separate east-west
33
 
and north-south spline step length arguments allows the user to account for some
34
 
degree of anisotropy in the distribution of observation points. Short spline
35
 
step lengths--especially spline step lengths that are less than the distance
36
 
between observation points--can greatly increase processing time.
37
 
 
38
 
<p>
39
 
Moreover, the maximum number of splines for each direction at each time is
40
 
fixed, regardless of the spline step length. As the total number of splines used
41
 
increases (i.e., with small spline step lengths), the region is automatically
42
 
into subregions for interpolation. Each subregion can contain no more than
43
 
150x150 splines. To avoid subregion boundary problems, subregions are created to
44
 
partially overlap each other. A weighted mean of observations, based on point
45
 
locations, is calculated within each subregion. 
46
 
 
47
 
<p>
48
 
The Tykhonov regularization parameter ("<b><i>lambda_i</i></b>") acts to smooth
49
 
the interpolation. With a small <b><i>lambda_i</i></b>, the interpolated surface
50
 
closely follows observation points; a larger value will produce a smoother
51
 
interpolation.
52
 
 
53
 
<p>
54
 
The input can be a 2D pr 3D vector points map. If "<b><i>layer =</i></b>" 0 the
55
 
z-value of a 3D map is used for interpolation. If layer > 0, the user must
56
 
specify an attribute column to used for interpolation using the
57
 
"<b><i>column=</i></b>" argument (2D or 3D map). 
58
 
 
59
 
<p>
60
 
v.surf.bspline can produce a raster OR a vector output (NOT simultaneously).
61
 
However, a vector output cannot be obtained using the default GRASS DBF driver. 
62
 
 
63
 
<p>
64
 
If output is a vector points map and a "<b><i>sparse=</i></b>" vector points map
65
 
is not specified, the output vector map will contain points at the same
66
 
locations as observation points in the input map, but the values of the output
67
 
points are interpolated values. If instead a "<b><i>sparse=</i></b>" vector points
68
 
map is specified, the output vector map will contain points at the same locations as
69
 
the sparse vector map points, and values will be those of the interpolated
70
 
raster surface at those points.
71
 
 
72
 
<p>
73
 
A cross validation "leave-one-out" analysis is available to help to determine
74
 
the optimal <b><i>lambda_i</i></b> value that produces an interpolation that
75
 
best fits the original observation data. The more points used for
76
 
cross-validation, the longer the time needed for computation. Empirical testing
77
 
indicates a threshold of a maximum of 100 points is recommended. Note that cross
78
 
validation can run very slowly if more than 100 observations are used. The
79
 
cross-validation output reports <i>mean</i> and <i>rms</i> of the residuals from
80
 
the true point value and the estimated from the interpolation for a fixed series
81
 
of <b><i>lambda_i</i></b> values. No vector nor raster output will be created
82
 
when cross-validation is selected. 
83
 
 
84
 
<h2>EXAMPLES</h2>
85
 
 
86
 
<h3>Basic interpolation</h3>
87
 
 
88
 
<div class="code"><pre>
89
 
v.surf.bspline input=point_vector output=interpolate_surface method=bicubic
90
 
</pre></div>
91
 
 
92
 
A bicubic spline interpolation will be done and a vector points map with estimated
93
 
(i.e., interpolated) values will be created. 
94
 
 
95
 
<h4>Basic interpolation and raster output with a longer spline step</h4>
96
 
 
97
 
<div class="code"><pre>
98
 
v.surf.bspline input=point_vector raster=interpolate_surface sie=25 sin=25
99
 
</pre></div>
100
 
 
101
 
A bilinear spline interpolation will be done with a spline step length of 25 map
102
 
units. An interpolated raster map will be created at the current region resolution.
103
 
 
104
 
<h4>Estimation of <b><i>lambda_i</i></b> parameter with a cross validation proccess</h4>
105
 
 
106
 
<div class="code"><pre>
107
 
v.surf.bspline -c input=point_vector 
108
 
</pre></div>
109
 
 
110
 
<h4>Estimation on sparse points</h4>
111
 
 
112
 
<div class="code"><pre>
113
 
v.surf.bspline input=point_vector sparse=sparse_points output=interpolate_surface
114
 
</pre></div>
115
 
 
116
 
An output map of vector points will be created, corresponding to the sparse vector map, with interpolated values.
117
 
 
118
 
<h4>Using attribute values instead Z-coordinates</h4>
119
 
<div class="code"><pre>
120
 
v.surf.bspline input=point_vector raster=interpolate_surface layer=1 column=attrib_column
121
 
</pre></div>
122
 
 
123
 
The interpolation will be done using the values in attrib_column, in the
124
 
table associated with layer 1.
125
 
 
126
 
<h2>BUGS</h2>
127
 
Known issues:
128
 
<p>
129
 
In order to avoid RAM memory problems, an auxiliary table is needed for
130
 
recording some intermediate calculations. This requires the "<b>GROUP BY</b>"
131
 
SQL function is used, which is not supported by the "<b>dbf</b>" driver. For
132
 
this reason, vector map output "<b><i>output=</i></b>" is not permitted with the
133
 
DBF driver. There are no problems with the raster map output from the DBF
134
 
driver.
135
 
 
136
 
<h2>SEE ALSO</h2>
137
 
 
138
 
<em>
139
 
<a href="v.surf.idw.html">v.surf.idw</a>,
140
 
<a href="v.surf.rst.html">v.surf.rst</a>
141
 
</em>
142
 
 
143
 
<h2>AUTHORS</h2>
144
 
 
145
 
Original version in GRASS 5.4: (s.bspline.reg)
146
 
<br>
147
 
Maria Antonia Brovelli, Massimiliano Cannata, Ulisse Longoni, Mirko Reguzzoni
148
 
<p>
149
 
Update for GRASS 6.X and improvements:
150
 
<br>
151
 
Roberto Antolin
152
 
 
153
 
<h2>REFERENCES</h2>
154
 
 
155
 
Brovelli M. A., Cannata M., and Longoni U.M., 2004, LIDAR Data
156
 
Filtering and DTM Interpolation Within GRASS, Transactions in GIS,
157
 
April 2004, vol. 8, iss. 2, pp. 155-174(20), Blackwell Publishing Ltd
158
 
<p>
159
 
Brovelli M. A. and Cannata M., 2004, Digital Terrain model
160
 
reconstruction in urban areas from airborne laser scanning data: the
161
 
method and an example for Pavia (Northern Italy). Computers and
162
 
Geosciences 30, pp.325-331
163
 
<p>
164
 
Brovelli M. A e Longoni U.M., 2003, Software per il filtraggio di
165
 
dati LIDAR, Rivista dell'Agenzia del Territorio, n. 3-2003, pp. 11-22
166
 
(ISSN 1593-2192)
167
 
<p>
168
 
Antolin R. and Brovelli M.A., 2007, LiDAR data Filtering with GRASS GIS for the 
169
 
Determination of Digital Terrain Models. Proceedings of Jornadas de SIG Libre,
170
 
Girona, Espa&ntilde;a. CD ISBN: 978-84-690-3886-9 <br>
171
 
 
172
 
<p><i>Last changed: $Date: 2012-12-27 18:22:59 +0100 (Thu, 27 Dec 2012) $</i>