vectorintro.html 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  2. <html>
  3. <head>
  4. <title>Vector data processing in GRASS GIS</title>
  5. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  6. <meta name="Author" content="Markus Neteler/GRASS Development Team">
  7. <link rel="stylesheet" href="grassdocs.css" type="text/css">
  8. </head>
  9. <body bgcolor="white">
  10. <img src="grass_logo.png" alt="_\|/_ GRASS logo"><hr align=center size=6 noshade>
  11. <h2>Vector data processing in GRASS GIS</h2>
  12. <h3>Vector maps in general</h3>
  13. A "vector map" is a data layer consisting of a number of sparse features
  14. in geographic space. These might be data points (drill sites), lines
  15. (roads), polygons (park boundary), volumes (3D CAD structure), or some
  16. combination of all these. Typically each feature in the map will be
  17. tied to a set of attribute layers stored in a database (road names,
  18. site ID, geologic type, etc.). As a general rule these can exist in 2D
  19. or 3D space and are independent of the GIS's computation region.
  20. <h3>Vector data import and export</h3>
  21. The <a href="v.in.ogr.html">v.in.ogr</a> module offers a common
  22. interface for many different vector formats. Additionally, it
  23. offers options such as on-the-fly creation of new locations or extension of
  24. the default region to match the extent of the imported vector map.
  25. For special cases, other import modules are available, e.g.
  26. <a href="v.in.ascii.html">v.in.ascii</a> for input from a text file
  27. containing coordinate and attribute data, and
  28. <a href="v.in.db.html">v.in.db</a> for input from a database containing
  29. coordinate and attribute data.
  30. With <a href="v.external.html">v.external</a> external maps can be
  31. virtually linked into a mapset, only pseudo-topology is generated but
  32. the vector geometry is not imported.
  33. The <em>v.out.*</em> set of commands exports to various formats. To import
  34. and export only attribute tables, use <a href="db.in.ogr.html">db.in.ogr</a>
  35. and <a href="db.out.ogr.html">db.out.ogr</a>.
  36. <h3>Metadata</h3>
  37. The <a href="v.info.html">v.info</a> display general information such
  38. as metadata and attribute columns about a vector map including the
  39. history how it was generated. Each map generating command stores the
  40. command history into the metadata (query with <a href="v.info.html">v.info -h mapname</a>).
  41. Metadata such as map title, scale, organization etc. can be updated
  42. with <a href="v.support.html">v.support</a>.
  43. <h3>Vector map operations</h3>
  44. GRASS vector map processing is always performed on the full map.
  45. If this is not desired, the input map has to be clipped to the
  46. current region beforehand (<a href="v.in.region.html">v.in.region</a>,
  47. <a href="v.overlay.html">v.overlay</a>,<a href="v.select.html">v.select</a>).
  48. <h3>Vector model and topology</h3>
  49. GRASS is a topological GIS. This means that adjacent geographic
  50. components in a single vector map are related. For example in a
  51. non-topological GIS if two areas shared a common border that border
  52. would be digitized two times and also stored in duplicate. In a
  53. topological GIS this border exists once and is shared between two
  54. areas. Topological represenation of vector data helps to produce and
  55. maintain vector maps with clean geometry as well as enables certain
  56. analyses that can not be conducted with non-topological or spaghetti
  57. data. In GRASS topological data are refered to as level 2 data and
  58. spaghetti data is referred to as level 1.
  59. <p>
  60. Sometimes topology is not necessary and the additional memory and
  61. space requirements are burdensome to a particular task. Therefore two
  62. modules allow for working level 1 (non-topological) data within
  63. GRASS. The <a href="v.in.ascii.html">v.in.ascii</a> module allows
  64. users to input points without building topology. This is very useful
  65. for large files where memory restrictions may cause difficulties. The
  66. other module which works with level 1 data is
  67. <a href="v.surf.rst.html">v.surf.rst</a> which enables spatial
  68. approximation and topographic analysis from a point or isoline file.
  69. <p> In GRASS, the following vector objects are defined:
  70. <ul>
  71. <li> point: a point; </li>
  72. <li> line: a directed sequence of connected vertices with two endpoints called nodes; </li>
  73. <li> boundary: the border line to describe an area; </li>
  74. <li> centroid: a point within a closed boundary; </li>
  75. <li> area: the topological composition of centroid and boundary; </li>
  76. <li> face: a 3D area; </li>
  77. <li> kernel: a 3D centroid in a volume (not yet implemented); </li>
  78. <li> volume: a 3D corpus, the topological composition of faces and kernel (not yet implemented). </li>
  79. </ul>
  80. <p>
  81. Note that all lines and boundaries can be polylines (with nodes in between).
  82. <P>
  83. The <a href="v.type.html">v.type</a> module can be used to convert
  84. between vector types if possible. The <a href="v.build.html">v.build</a>
  85. module is used to generate topology. It optionally allows to extract
  86. the erroneous vector objects into a separate map. Topological errors
  87. can be corrected either manually within <a href="v.digit.html">v.digit</a>
  88. or, to some extent, automatically in <a href="v.clean.html">v.clean</a>.
  89. A dedicated vector editing module is <a href="v.edit.html">v.edit</a>
  90. which supports global and local editing operations. Additionally,
  91. new advanced topological operations are available in the
  92. <a href="wxGUI.Vector_Digitizing_Tool.html">new digitizing tool</a>.
  93. Adjacent polygons can be found by <a href="v.to.db.html">v.to.db</a>
  94. (see 'sides' option).
  95. <P>
  96. Many operations including extraction, queries, overlay, and export will
  97. only act on features which have been assigned a category number. Typically
  98. a centroid will hold the attribute data for the area between it and its
  99. boundary. Boundaries are not typically given a category ID as it would be
  100. ambiguous as to which area either side of it the attribute data would belong
  101. to. An exception might be when the boundary between two crop-fields is the
  102. center-line of a road, and the category information is an index to the road
  103. name. For everyday use boundaries and centroids can be treated as internal
  104. data types and the user can work directly and more simply with the "area"
  105. meta-feature type.
  106. <h3>Attribute management</h3>
  107. GRASS can be linked to one or many database management systems (DBMS).
  108. The <em>db.*</em> set of commands provides basic SQL support for
  109. attribute management, while the <em>v.db.*</em> set of commands operates
  110. on the vector map.
  111. <ul>
  112. <li><b>Categories:</b> The category number is the vector ID. It is
  113. used to link attribute(s) to each vector object. A vector object can
  114. have zero, one, two, or more categories. Category numbers are stored
  115. both within the geometry file and within the attribute table(s) for each
  116. vector object (usually the "cat" column).
  117. Using <a href="v.category.html">v.category</a>, category numbers can be
  118. printed or maintained. In order to link one vector object to several
  119. attribute tables, several category numbers per vector object are needed.
  120. </li>
  121. <li><b>Layers:</b> It is possible to link the geographic objects in
  122. a vector map to one or more tables. Each link to a distinct
  123. attribute table is called a layer. A link defines which database
  124. driver, database and table is to be used. Each category numbers
  125. in a geometry file corresponds to a row in the attribute table
  126. (the linking column is usually the "cat" key column). Using
  127. <a href="v.db.connect.html">v.db.connect</a> layers can be listed
  128. or maintained.<br>
  129. GRASS layers do not contain any geographic objects, but they
  130. consist of links to attribute tables in which vector objects
  131. can have zero, one or more categories. If a vector object
  132. has zero categories in a layer, then it does not appear in that
  133. layer. In this fashion some vector objects may appear in some layers
  134. but not in others. The practical benefit of this system is that it
  135. allows placement of thematically distinct but topologically related
  136. objects into a single map (e.g. forests and lakes). These virtual
  137. layers are also useful for linking time series attribute data to a
  138. series of locations that did not change over time. By default the
  139. first layer is active, i.e. the first table corresponds to the first
  140. layer. Further tables are linked to subsequent layers.
  141. </li>
  142. <li><b>SQL support:</b> The DBF driver provides only very limited SQL
  143. support (as DBF is not an SQL DB) while the other DBMS backends (such
  144. as PostgreSQL, MySQL etc) provide full SQL support since the SQL
  145. commands are sent directly to the DBMI. SQL commands can be directly
  146. executed with <a href="db.execute.html">db.execute</a>,
  147. <a href="db.select.html">db.select</a> and the other db.* modules.
  148. </li>
  149. </ul>
  150. When creating vector maps from scratch, in general an attribute table must be created and
  151. the table must be populated with one row per category (using <a href="v.to.db.html">v.to.db</a>).
  152. However, this can be performed in a single step using <a href="v.db.addtable.html">v.db.addtable</a>
  153. along with the definition of table column types. Column adding and dropping
  154. can be done with <a HREF="v.db.addcol.html">v.db.addcol</a> and
  155. <a HREF="v.db.dropcol.html">v.db.dropcol</a>. A table column can be renamed with
  156. <a HREF="v.db.renamecol.html">v.db.renamecol</a>. To drop a table from a map, use
  157. <a HREF="v.db.droptable.html">v.db.droptable</a>. Values in a table can be updated
  158. with <a HREF="v.db.update.html">v.db.update</a>. Tables can be joined with with
  159. <a HREF="v.db.join.html">v.db.join</a>.
  160. <h3>Editing vector attributes</h3>
  161. To manually edit attributes of a table, the map has to be
  162. queried in 'edit mode' using <a href="d.what.vect.html">d.what.vect</a>.
  163. To bulk process attributes, it is recommended to use SQL
  164. (<a href="db.execute.html">db.execute</a>).
  165. <h3>Geometry operations</h3>
  166. The module <a href="v.in.region.html">v.in.region</a> saves the
  167. current region boundary into a vector area.
  168. Split vector lines can be changes to polylines by
  169. <a href="v.build.polylines.html">v.build.polylines</a>. Long lines can be
  170. split by <a href="v.split.html">v.split</a> and
  171. <a href="v.segment.html">v.segment</a>.
  172. Buffer and circles can be generated with <a href="v.buffer.html">v.buffer</a>
  173. and <a href="v.parallel.html">v.parallel</a>.
  174. <a href="v.generalize.html">v.generalize</a> is module for generalization of GRASS vector maps.
  175. 2D vector maps can be changed to 3D using
  176. <a href="v.drape.html">v.drape</a> or <a href="v.extrude.html">v.extrude</a>.
  177. If needed, the spatial position of vector points can be perturbed by
  178. <a href="v.perturb.html">v.perturb</a>.
  179. The <a href="v.type.html">v.type</a> command changes between vector
  180. types (see list above).
  181. Projected vector maps can be reprojected with <a href="v.proj.html">v.proj</a>.
  182. Unprojected maps can be geocoded with <a href="v.transform.html">v.transform</a>.
  183. Triangulation and point-to-polygon conversions can be done with <a
  184. href="v.delaunay.html">v.delaunay</a>, <a href="v.hull.html">v.hull</a>,
  185. and <a href="v.voronoi.html">v.voronoi</a>.
  186. The <a href="v.random.html">v.random</a> command generated random points.
  187. <h3>Vector overlays and selections</h3>
  188. Geometric overlay of vector maps is done with <a href="v.patch.html">v.patch</a>,
  189. <a href="v.overlay.html">v.overlay</a> and <a href="v.select.html">v.select</a>,
  190. depending on the combination of vector types.
  191. Vectors can be extracted with <a href="v.extract.html">v.extract</a>
  192. and reclassified with <a href="v.reclass.html">v.reclass</a>.
  193. <h3>Vector statistics</h3>
  194. Statistics can be generated by <a href="v.qcount.html">v.qcount</a>,
  195. <a href="v.sample.html">v.sample</a>, <a href="v.normal.html">v.normal</a>,
  196. and <a href="v.univar.html">v.univar</a>.
  197. Distances between vector objects are calculated with <a href="v.distance.html">v.distance</a>.
  198. <h3>Vector-Raster-DB conversion</h3>
  199. The <a href="v.to.db.html">v.to.db</a> transfers vector information
  200. into database tables.
  201. With <a href="v.to.points.html">v.to.points</a>,
  202. <a href="v.to.rast.html">v.to.rast</a> and <a href="v.to.rast3.html">v.to.rast3</a>
  203. conversions are performed.
  204. <h3>Vector queries</h3>
  205. Vector maps can be queried with <a href="v.what.html">v.what</a> and
  206. <a href="v.what.vect.html">v.what.vect</a>.
  207. <h3>Vector-Raster queries</h3>
  208. Raster values can be transferred to vector maps with
  209. <a href="v.what.rast.html">v.what.rast</a> and
  210. <a href="v.rast.stats">v.rast.stats</a>.
  211. <h3>Vector network analysis</h3>
  212. GRASS provides support for vector network analysis. The following algorithms
  213. are implemented:
  214. <ul>
  215. <li> Vector maintenance: <a href="v.net.html">v.net</a></li>
  216. <li> Shortest path: <a href="d.path.html">d.path</a> and
  217. <a href="v.net.path.html">v.net.path</a></li>
  218. <li> Traveling salesman (round trip): <a href="v.net.salesman.html">v.net.salesman</a></li>
  219. <li> Allocation of sources (create subnetworks, e.g. police station zones):
  220. <a href="v.net.alloc.html">v.net.alloc</a></li>
  221. <li> Minimum Steiner trees (star-like connections, e.g. broadband cable
  222. connections): <a href="v.net.steiner.html">v.net.steiner</a></li>
  223. <li> Iso-distances (from centers): <a href="v.net.iso.html">v.net.iso</a></li>
  224. </ul>
  225. Vector directions are defined by the digitizing direction (a--&gt;--b).
  226. Both directions are supported, network modules provide parameters
  227. to assign attribute columns to the forward and backward direction.
  228. <h3>Vector networks: Linear referencing system (LRS)</h3>
  229. LRS uses linear features and distance measured along those features to
  230. positionate objects. There are the commands
  231. <a href="v.lrs.create.html">v.lrs.create</a> to create a linear reference system,
  232. <a href="v.lrs.label.html">v.lrs.label</a> to create stationing on the LRS,
  233. <a href="v.lrs.segment.html">v.lrs.segment</a> to create points/segments on LRS,
  234. and
  235. <a href="v.lrs.where.html">v.lrs.where</a> to find line id and real km+offset
  236. for given points in vector map using linear reference system.
  237. <p>
  238. The <a href="lrs.html">LRS tutorial</a> explains further details.
  239. <h3>Interpolation and approximation</h3>
  240. Some of the vector modules deal with spatial or volumetric
  241. approximation (also called interpolation):
  242. <a href="v.kernel.html">v.kernel</a>,
  243. <a href="v.surf.idw.html">v.surf.idw</a>,
  244. <a href="v.surf.rst.html">v.surf.rst</a>, and
  245. <a href="v.vol.rst.html">v.vol.rst</a>.
  246. <h3>Lidar data processing</h3>
  247. Lidar point clouds (first and last return) are imported with <a
  248. href="v.in.ascii.html">v.in.ascii</a> (-b flag to not build the
  249. topology). Outlier detection is done with
  250. <a href="v.outlier.html">v.outlier</a> on both first and last return data.
  251. Then, with <a href="v.lidar.edgedetection.html">v.lidar.edgedetection</a>,
  252. edges are detected from last return data. The building are generated by
  253. <a href="v.lidar.growing.html">v.lidar.growing</a> from detected
  254. edges. The resulting data are post-processed with
  255. <a href="v.lidar.correction.html">v.lidar.correction</a>. Finally, the
  256. DTM and DSM are generated with <a href="v.surf.bspline.html">v.surf.bspline</a>
  257. (DTM: uses the 'v.lidar.correction' output; DSM: uses last return output
  258. from outlier detection).
  259. <h3>See also</h3>
  260. <ul>
  261. <li><a href="databaseintro.html">Introduction to GRASS database management</a></li>
  262. <li><a href="rasterintro.html">Introduction to GRASS raster map processing</a></li>
  263. <li><a href="raster3dintro.html">Introduction to GRASS 3D raster map (voxel) processing</a></li>
  264. </ul>
  265. <HR>
  266. <BR>
  267. <a href="index.html">Main index</a> - <a href="vector.html">vector index</a> - <a href="full_index.html">full index</a>
  268. <P>&copy; 2008 <a href="http://grass.osgeo.org">GRASS Development Team</a></P>
  269. </body>
  270. </html>