r.viewshed.html 8.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212
  1. <h2>DESCRIPTION</h2>
  2. <p><em>r.viewshed</em> is a module that computes the viewshed of a
  3. point on a raster terrain. That is, given an elevation raster, and the
  4. location of an observer, it generates a raster output map showing
  5. which cells are visible from the given location.
  6. The algorithm underlying <em>r.viewshed</em> minimizes both the CPU
  7. operations and the transfer of data between main memory and disk; as a
  8. result <em>r.viewshed</em> runs fast on very large rasters.
  9. <h3>Options and flags:</h3>
  10. To run <em>r.viewshed</em>, the user must specify an input map name,
  11. an output map name, and the location of the viewpoint.
  12. <p>Viewpoint (<em>coordinate</em> parameter): For the time being the viewpoint
  13. is assumed to be located inside the terrain. The viewpoint location is
  14. given in map coordinates.
  15. <p>Output: The output map may have one of three possible formats,
  16. based on which flags are set.
  17. <p>
  18. By default, if no flag is set, the output is in angle-mode, and
  19. each point in the output map is marked as NULL if the point is not
  20. visible or the respective point in the elevation map is NULL.
  21. Otherwise, a value in [0, 180] representing the vertical angle with
  22. regard to the viewpoint, in degrees, if the point is visible.
  23. 0 degrees: directly above the observer,
  24. 180 degrees: directly below the observer
  25. <p>
  26. If the <b>-b</b> flag is set, the output is in boolean-mode, and each point
  27. in the output map is marked as:
  28. <ul>
  29. <li> 0 if the point is Nodata/null or not visible
  30. <li> 1 if the point is visible.
  31. </ul>
  32. <p>
  33. If the <b>-e</b> flag is set, the output is in elevation-mode, and each point
  34. in the output map is marked as:
  35. <!-- Check & FIXME -->
  36. <ul>
  37. <li> Nodata (null), if the respective point in the elevation map is Nodata (null)
  38. <li> -1, if the point is not visible
  39. <li> the difference in elevation between the point and the viewpoint, if the point is visible.
  40. </ul>
  41. <p>
  42. If you wish to identify the area of the map which is within the search
  43. radius but not visible, a combination of <em>r.buffer</em> and
  44. <em>r.mapcalc</em> can be used to create a negative of the viewshed map.
  45. <p>
  46. Curvature of the earth: By default the elevations are not adjusted for
  47. the curvature of the earth. The user can turn this on with flag
  48. <b>-c</b>.
  49. <p>
  50. Observer elevation: By default the observer is assumed to have
  51. height=0 above the terrain. The user can change this using option
  52. <em>obs_elev=...</em>. The value entered is in the same units
  53. as the elevation.
  54. <p>
  55. Target elevation: By default the target is assumed to have
  56. height=0 above the terrain. The user can change this using option
  57. <em>tgt_elev=...</em> to determine if objects of a given height would be
  58. visible. The value entered is in the same units as the elevation.
  59. <p>
  60. Maximum visibility distance: By default there is no restriction on
  61. the maximum distance to which the observer can see. The user can set
  62. a maximum distance of visibility using option <em>max_dist=...</em>.
  63. The value entered is in the same units as the cell size of the raster.
  64. <p>
  65. Main memory usage: By default <em>r.viewshed</em> assumes it has
  66. 500MB of main memory, and sets up its internal data structures so that
  67. it does not require more than this amount of RAM. The user can set
  68. the amount of memory used by the program by setting the
  69. <em>memory_usage</em> to the number of MB of memory they would like to
  70. be used.
  71. <h3>Memory mode</h3>
  72. The algorithm can run in two modes: in internal memory, which
  73. means that it keeps all necessary data structures in memory during the
  74. computation. And in external memory, which means that the data
  75. structures are external, i.e. on disk. <em>r.viewshed</em> decides
  76. which mode to run in using the amount of main memory specified by the
  77. user. The internal mode is (much) faster than the external mode.
  78. <p>
  79. Ideally, the user should specify on the command line the amount of
  80. physical memory that is free for the program to use. Underestimating
  81. the memory may result in <em>r.viewshed</em> running in external mode
  82. instead of internal, which is slower. Overestimating the amount of
  83. free memory may result in <em>r.viewshed</em> running in internal mode
  84. and using virtual memory, which is slower than the external mode.
  85. <h3>The algorithm:</h3>
  86. <em>r.viewshed</em> uses the following model for determining
  87. visibility: The height of a cell is assumed to be variable, and the
  88. actual height of a point falling into a cell, but not identical the cell
  89. center, is interpolated. Thus the terrain is viewed as a smooth surface.
  90. Two points are visible to each other if their line-of-sight does not
  91. intersect the terrain. The height for an arbitrary point x in the terrain
  92. is interpolated from the 4 surrounding neighbours. This means that this
  93. model does a linear (bilinear) interpolation of heights.
  94. This model is suitable for both low and high resolution rasters as well
  95. as terrain with flat and steep slopes.
  96. <p>The core of the algorithm is determining, for each cell, the
  97. line-of-sight and its intersections with the cells in the terrain. For
  98. a (square) grid of <em>n</em> cells, there can be <em>O(n
  99. <sup>1/2</sup>)</em> cells that intersect the LOS. If we test every
  100. single such cell for every point in the grid, this adds up to
  101. <em>O(n<sup>3/2</sup>)</em> tests. We can do all these tests faster if
  102. we re-use information from one point to the next (two grid points that
  103. are close to each other will be intersected by a lot of the same
  104. points) and organize the computation differently.
  105. <p>More precisely, the algorithm uses a technique called <em>line
  106. sweeping</em>: It considers a half-line centered at the viewpoint, and
  107. rotates it radially around the viewpoint, 360 degrees. During the
  108. sweep it keeps track of all the cells that intersect the sweep line at
  109. that time; These are called the <em>active</em> cells. A cell has 3
  110. associated events: when it is first met by the sweep line and inserted
  111. into the active structure; when it is last met by the sweep line and
  112. deleted from the active structure; and when the sweep line passes over
  113. its centerpoint, at which time its visibility is determined. To
  114. determine the visibility of a cell all cells that intersect the
  115. line-of-sight must be active, so they are in the active structure.
  116. The algorithm looks at all the active cells that are between the point
  117. and the viewpoint, and finds the maximum gradient among these. If the
  118. cell's gradient is higher, it is marked as visible, whereas if it is
  119. lower, it is marked as invisible.
  120. <p>For a (square) raster of <em>n</em> point in total, the standard
  121. viewshed algorithm uses <em>O(n sqrt(n))= O(n<sup>3/2</sup>)</em>
  122. time, while the sweep-line algorithm uses <em>O(n lg n)</em> time.
  123. This algorithm is efficient in terms of CPU operations and can be also
  124. made efficient in terms of I/O-operations. For all details see the
  125. REFERENCES below.
  126. <p>
  127. <table width=50% align=center>
  128. <tr>
  129. <th><img src="sweep1.png" width=200 alt="[SDF]" border=0></th>
  130. <th><img src="sweep2.png" width=200 alt="[SDF]" border=0></th>
  131. </tr>
  132. <tr>
  133. <th>The sweep-line.</th>
  134. <th>The active cells.</th>
  135. </tr>
  136. </table>
  137. <h3>An example:</h3>
  138. Using the Spearfish dataset: calculating the viewpoint from the top
  139. of a mountain:
  140. <div class="code"><pre>
  141. g.region rast=elevation.10m
  142. r.viewshed input=elevation.10m output=viewshed coordinate=598869,4916642 mem=800
  143. </pre></div>
  144. <h3>REFERENCES</h3>
  145. <ul>
  146. <li>Computing Visibility on Terrains in External Memory. Herman
  147. Haverkort, Laura Toma and Yi Zhuang. To appear in <em>ACM Journal
  148. on Experimental Algorithmics</em>.
  149. <li><a
  150. href="http://www.siam.org/proceedings/alenex/2007/alx07_002haverkorth.pdf">
  151. Computing Visibility on Terrains in External Memory</a>. Herman
  152. Haverkort, Laura Toma and Yi Zhuang. In the <em>Proceedings of
  153. the 9th Workshop on Algorithm Engineering and Experiments /
  154. Workshop on Analytic Algorithms and Combinatorics (ALENEX/ANALCO
  155. 2007)</em>.</li>
  156. </ul>
  157. <h3>AUTHORS</h3>
  158. <p>Laura Toma (Bowdoin College): <tt>ltoma@bowdoin.edu</tt>
  159. <p> Yi Zhuang (Carnegie-Mellon University): <tt>yzhuang@andrew.cmu.edu</tt>
  160. <p>William Richard (Bowdoin College): <tt>willster3021@gmail.com </tt>
  161. <p>Markus Metz
  162. <p>
  163. <i>Last changed: $Date$</i>