vectorintro.html 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377
  1. <!-- meta page description: Vector data processing in GRASS GIS -->
  2. <!-- meta page index: vector -->
  3. <h3>Vector maps in general</h3>
  4. A "vector map" is a data layer consisting of a number of sparse features
  5. in geographic space. These might be data points (drill sites), lines
  6. (roads), polygons (park boundary), volumes (3D CAD structure), or some
  7. combination of all these. Typically each feature in the map will be
  8. tied to a set of attribute layers stored in a database (road names,
  9. site ID, geologic type, etc.). As a general rule these can exist in 2D
  10. or 3D space and are independent of the GIS's computation region.
  11. <h3>Vector data import and export</h3>
  12. The <a href="v.in.ogr.html">v.in.ogr</a> module offers a common
  13. interface for many different vector formats. Additionally, it
  14. offers options such as on-the-fly creation of new locations or extension of
  15. the default region to match the extent of the imported vector map.
  16. For special cases, other import modules are available, e.g.
  17. <a href="v.in.ascii.html">v.in.ascii</a> for input from a text file
  18. containing coordinate and attribute data, and
  19. <a href="v.in.db.html">v.in.db</a> for input from a database containing
  20. coordinate and attribute data.
  21. With <a href="v.external.html">v.external</a> external maps can be
  22. virtually linked into a mapset, only pseudo-topology is generated but
  23. the vector geometry is not imported.
  24. The <em>v.out.*</em> set of commands exports to various formats. To import
  25. and export only attribute tables, use <a href="db.in.ogr.html">db.in.ogr</a>
  26. and <a href="db.out.ogr.html">db.out.ogr</a>.
  27. The naming convention for vector maps requires that map names start with a
  28. character, not a number (map name scheme: [A-Za-z][A-Za-z0-9_]*).
  29. <h3>Metadata</h3>
  30. The <a href="v.info.html">v.info</a> display general information such
  31. as metadata and attribute columns about a vector map including the
  32. history how it was generated. Each map generating command stores the
  33. command history into the metadata (query with <a href="v.info.html">v.info -h mapname</a>).
  34. Metadata such as map title, scale, organization etc. can be updated
  35. with <a href="v.support.html">v.support</a>.
  36. <h3>Vector map operations</h3>
  37. GRASS vector map processing is always performed on the full map.
  38. If this is not desired, the input map has to be clipped to the
  39. current region beforehand (<a href="v.in.region.html">v.in.region</a>,
  40. <a href="v.overlay.html">v.overlay</a>,<a href="v.select.html">v.select</a>).
  41. <h3>Vector model and topology</h3>
  42. GRASS is a topological GIS. This means that adjacent geographic
  43. components in a single vector map are related. For example in a
  44. non-topological GIS if two areas shared a common border that border
  45. would be digitized two times and also stored in duplicate. In a
  46. topological GIS this border exists once and is shared between two
  47. areas. Topological represenation of vector data helps to produce and
  48. maintain vector maps with clean geometry as well as enables certain
  49. analyses that can not be conducted with non-topological or spaghetti
  50. data. In GRASS topological data are refered to as level 2 data and
  51. spaghetti data is referred to as level 1.
  52. <p>
  53. Sometimes topology is not necessary and the additional memory and
  54. space requirements are burdensome to a particular task. Therefore two
  55. modules allow for working level 1 (non-topological) data within
  56. GRASS. The <a href="v.in.ascii.html">v.in.ascii</a> module allows
  57. users to input points without building topology. This is very useful
  58. for large files where memory restrictions may cause difficulties. The
  59. other module which works with level 1 data is
  60. <a href="v.surf.rst.html">v.surf.rst</a> which enables spatial
  61. approximation and topographic analysis from a point or isoline file.
  62. <p> In GRASS, the following vector object types are defined:
  63. <ul>
  64. <li> point: a point; </li>
  65. <li> line: a directed sequence of connected vertices with two endpoints called nodes; </li>
  66. <li> boundary: the border line to describe an area; </li>
  67. <li> centroid: a point within a closed ring of boundaries; </li>
  68. <li> area: the topological composition of a closed ring of boundaries and optionally a centroid; </li>
  69. <li> face: a 3D area; </li>
  70. <li> kernel: a 3D centroid in a volume (not yet implemented); </li>
  71. <li> volume: a 3D corpus, the topological composition of faces and kernel (not yet implemented). </li>
  72. </ul>
  73. <p>
  74. Note that all lines and boundaries can be polylines (with vertices in between).
  75. <p>
  76. Area topology also holds information about isles. These isles are located
  77. within that area, not touching the boundaries of the outer area. Isles
  78. consist of one or more areas and are used internally to maintain correct
  79. topology for areas.
  80. <p>
  81. The <a href="v.type.html">v.type</a> module can be used to convert
  82. between vector types if
  83. possible. The <a href="v.build.html">v.build</a> module is used to
  84. generate topology. It optionally allows to extract the erroneous
  85. vector objects into a separate map. Topological errors can be
  86. corrected either manually
  87. within <a href="wxGUI.Vector_Digitizer.html">wxGUI vector
  88. digitizer</a> or, to some extent, automatically
  89. in <a href="v.clean.html">v.clean</a>. A dedicated vector editing
  90. module is <a href="v.edit.html">v.edit</a> which supports global and
  91. local editing operations.
  92. Adjacent polygons can be found by <a href="v.to.db.html">v.to.db</a>
  93. (see 'sides' option).
  94. <p>
  95. Many operations including extraction, queries, overlay, and export will
  96. only act on features which have been assigned a category number. Typically
  97. a centroid will hold the attribute data for the area between it and its
  98. boundaries. Boundaries are not typically given a category ID as it would be
  99. ambiguous as to which area either side of it the attribute data would belong
  100. to. An exception might be when the boundary between two crop-fields is the
  101. center-line of a road, and the category information is an index to the road
  102. name. For everyday use boundaries and centroids can be treated as internal
  103. data types and the user can work directly and more simply with the "area"
  104. meta-feature type.
  105. <h3>Vector object categories and attribute management</h3>
  106. GRASS vectors can be linked to one or many database management systems
  107. (DBMS). The <em>db.*</em> set of commands provides basic SQL support for
  108. attribute management, while the <em>v.db.*</em> set of commands operates
  109. on a table linked to a vector map.
  110. <ul>
  111. <li><b>Categories</b><br>
  112. Categories are used to categorize vector objects and link
  113. attribute(s) to each category. Each vector object can have zero, one or
  114. several categories. Category numbers do not have to be unique for
  115. each vector object, several vector objects can share the same category.
  116. <br>Category numbers are stored both within the geometry file for each
  117. vector object and within the (optional) attribute table(s) (usually the "cat"
  118. column). It is not required that attribute table(s) hold an entry for
  119. each category, and attribute table(s) can hold
  120. information about categories not present in the vector geometry file.
  121. This means that e.g. an attribute table can be populated first and then
  122. vector objects can be added to the geometry file with category numbers.
  123. Using <a href="v.category.html">v.category</a>, category numbers can be
  124. printed or maintained.
  125. <br><br></li>
  126. <li><b>Layers</b><br>
  127. Layers are a characteristic of the vector feature (geometries) file.
  128. As mentioned above, categories allow the user to give either a
  129. unique id to each feature or to group similar features by giving
  130. them all the same id. Layers allow several parallel, but different
  131. groupings of features in a same map. The practical benefit of this
  132. system is that it allows placement of thematically distinct but
  133. topologically related objects into a single map, or for linking time
  134. series attribute data to a series of locations that did not change
  135. over time.
  136. <br>
  137. For example, one can have roads with one layer
  138. containing the unique id of each road and another layer with ids for
  139. specific routes that one might take, combining several roads by
  140. assigning the same id. While this example can also be dealt with in
  141. an attribute table, another example of the use of layers that shows
  142. their specific advantage is the possibility to identify the same geometrical
  143. features as representing different thematic objects. For example,
  144. in a map with a series of polygons representing fields in
  145. which at the same time the boundaries of these fields have a meaning
  146. as linear features, e.g. as paths, one can give a unique id to each
  147. field as area in layer 1, and a unique id in layer 2 to those
  148. boundary lines that are paths. If the paths will always depend on
  149. the field boundaries (and might change if these boundaries
  150. change) then keeping them in the same map can be helpful. Trying
  151. to reproduce the same functionality through attributes is much more
  152. complicated.
  153. <br>
  154. If a vector object has zero categories in a layer, then it does not
  155. appear in that layer. In this fashion some vector objects may appear
  156. in some layers but not in others. Taking the example of the fields
  157. and paths, only some boundaries, but not all, might have a category
  158. value in layer 2. With <em>option=report</em>,
  159. <a href="v.category.html">v.category</a> lists available categories
  160. in each layer.
  161. <br>
  162. Optionally, each layer can (but does not have
  163. to) be linked to an attribute table. The link is made by the
  164. category values of the features in that layer which have to have
  165. corresponding entries in the specified key column of the table.
  166. Using <a href="v.db.connect.html">v.db.connect</a> connections
  167. between layers and attribute tables can be listed or maintained.
  168. <br>
  169. In most modules, the first layer (<em>layer=1</em>) is active by
  170. default. Using <em>layer=-1</em> one can access all layers.
  171. </li>
  172. <li><b>SQL support</b><br>
  173. The DBF driver provides only very limited SQL support (as DBF is not an
  174. SQL DB) while the other DBMS backends (such as SQLite, PostgreSQL, MySQL
  175. etc) provide full SQL support since the SQL commands are sent directly
  176. to the DBMI. SQL commands can be directly executed with
  177. <a href="db.execute.html">db.execute</a>,
  178. <a href="db.select.html">db.select</a> and the other db.* modules.
  179. </li>
  180. </ul>
  181. When creating vector maps from scratch, in general an attribute table must be created and
  182. the table must be populated with one row per category (using <a href="v.to.db.html">v.to.db</a>).
  183. However, this can be performed in a single step using <a href="v.db.addtable.html">v.db.addtable</a>
  184. along with the definition of table column types. Column adding and dropping
  185. can be done with <a href="v.db.addcolumn.html">v.db.addcolumn</a> and
  186. <a href="v.db.dropcolumn.html">v.db.dropcolumn</a>. A table column can be renamed with
  187. <a href="v.db.renamecolumn.html">v.db.renamecolumn</a>. To drop a table from a map, use
  188. <a href="v.db.droptable.html">v.db.droptable</a>. Values in a table can be updated
  189. with <a href="v.db.update.html">v.db.update</a>. Tables can be joined with with
  190. <a href="v.db.join.html">v.db.join</a>.
  191. <h3>Editing vector attributes</h3>
  192. To manually edit attributes of a table, the map has to be
  193. queried in 'edit mode' using <a href="d.what.vect.html">d.what.vect</a>.
  194. To bulk process attributes, it is recommended to use SQL
  195. (<a href="db.execute.html">db.execute</a>).
  196. <h3>Geometry operations</h3>
  197. The module <a href="v.in.region.html">v.in.region</a> saves the
  198. current region boundary into a vector area.
  199. Split vector lines can be changes to polylines by
  200. <a href="v.build.polylines.html">v.build.polylines</a>. Long lines can be
  201. split by <a href="v.split.html">v.split</a> and
  202. <a href="v.segment.html">v.segment</a>.
  203. Buffer and circles can be generated with <a href="v.buffer.html">v.buffer</a>
  204. and <a href="v.parallel.html">v.parallel</a>.
  205. <a href="v.generalize.html">v.generalize</a> is module for generalization of GRASS vector maps.
  206. 2D vector maps can be changed to 3D using
  207. <a href="v.drape.html">v.drape</a> or <a href="v.extrude.html">v.extrude</a>.
  208. If needed, the spatial position of vector points can be perturbed by
  209. <a href="v.perturb.html">v.perturb</a>.
  210. The <a href="v.type.html">v.type</a> command changes between vector
  211. types (see list above).
  212. Projected vector maps can be reprojected with <a href="v.proj.html">v.proj</a>.
  213. Unprojected maps can be geocoded with <a href="v.transform.html">v.transform</a>.
  214. Based on the control points, <a href="v.rectify.html">v.rectify</a> rectifies a
  215. vector map by computing a coordinate transformation for each vector object.
  216. Triangulation and point-to-polygon conversions can be done with <a
  217. href="v.delaunay.html">v.delaunay</a>, <a href="v.hull.html">v.hull</a>,
  218. and <a href="v.voronoi.html">v.voronoi</a>.
  219. The <a href="v.random.html">v.random</a> command generated random points.
  220. <h3>Vector overlays and selections</h3>
  221. Geometric overlay of vector maps is done with <a href="v.patch.html">v.patch</a>,
  222. <a href="v.overlay.html">v.overlay</a> and <a href="v.select.html">v.select</a>,
  223. depending on the combination of vector types.
  224. Vectors can be extracted with <a href="v.extract.html">v.extract</a>
  225. and reclassified with <a href="v.reclass.html">v.reclass</a>.
  226. <h3>Vector statistics</h3>
  227. Statistics can be generated by <a href="v.qcount.html">v.qcount</a>,
  228. <a href="v.sample.html">v.sample</a>, <a href="v.normal.html">v.normal</a>,
  229. and <a href="v.univar.html">v.univar</a>.
  230. Distances between vector objects are calculated with <a href="v.distance.html">v.distance</a>.
  231. <h3>Vector-Raster-DB conversion</h3>
  232. The <a href="v.to.db.html">v.to.db</a> transfers vector information
  233. into database tables.
  234. With <a href="v.to.points.html">v.to.points</a>,
  235. <a href="v.to.rast.html">v.to.rast</a> and <a href="v.to.rast3.html">v.to.rast3</a>
  236. conversions are performed.
  237. <h3>Vector queries</h3>
  238. Vector maps can be queried with <a href="v.what.html">v.what</a> and
  239. <a href="v.what.vect.html">v.what.vect</a>.
  240. <h3>Vector-Raster queries</h3>
  241. Raster values can be transferred to vector maps with
  242. <a href="v.what.rast.html">v.what.rast</a> and
  243. <a href="v.rast.stats">v.rast.stats</a>.
  244. <h3>Vector network analysis</h3>
  245. GRASS provides support for vector network analysis. The following algorithms
  246. are implemented:
  247. <ul>
  248. <li> Network preparation and maintenance: <a href="v.net.html">v.net</a></li>
  249. <li> Shortest path: <a href="d.path.html">d.path</a> and
  250. <a href="v.net.path.html">v.net.path</a></li>
  251. <li> Shortest path between all pairs of nodes <a href="v.net.allpairs.html">v.net.allpairs</a>
  252. <li> Allocation of sources (create subnetworks, e.g. police station zones):
  253. <a href="v.net.alloc.html">v.net.alloc</a></li>
  254. <li> Iso-distances (from centers): <a href="v.net.iso.html">v.net.iso</a></li>
  255. <li> Computes bridges and articulation points: <a href="v.net.bridge.html">v.net.bridge</a></li>
  256. <li> Computes degree, centrality, betweeness, closeness and eigenvector centrality measures: <a href="v.net.centrality.html">v.net.centrality</a></li>
  257. <li> Computes strongly and weakly connected components: <a href="v.net.components.html">v.net.components</a></li>
  258. <li> Computes vertex connectivity between two sets of nodes: <a href="v.net.connectivity.html">v.net.connectivity</a></li>
  259. <li> Computes shortest distance via the network between the given sets of features: <a href="v.net.distance.html">v.net.distance</a></li>
  260. <li> Computes the maximum flow between two sets of nodes: <a href="v.net.flow.html">v.net.flow</a></li>
  261. <li> Computes minimum spanning tree:<a href="v.net.spanningtree.html">v.net.spanningtree</a></li>
  262. <li> Minimum Steiner trees (star-like connections, e.g. broadband cable
  263. connections): <a href="v.net.steiner.html">v.net.steiner</a></li>
  264. <li> Finds shortest path using timetables: <a href="v.net.timetable.html">v.net.timetable</a></li>
  265. <li> Traveling salesman (round trip): <a href="v.net.salesman.html">v.net.salesman</a></li>
  266. </ul>
  267. Vector directions are defined by the digitizing direction (a--&gt;--b).
  268. Both directions are supported, most network modules provide parameters
  269. to assign attribute columns to the forward and backward direction.
  270. <h3>Vector networks: Linear referencing system (LRS)</h3>
  271. LRS uses linear features and distance measured along those features to
  272. positionate objects. There are the commands
  273. <a href="v.lrs.create.html">v.lrs.create</a> to create a linear reference system,
  274. <a href="v.lrs.label.html">v.lrs.label</a> to create stationing on the LRS,
  275. <a href="v.lrs.segment.html">v.lrs.segment</a> to create points/segments on LRS,
  276. and
  277. <a href="v.lrs.where.html">v.lrs.where</a> to find line id and real km+offset
  278. for given points in vector map using linear reference system.
  279. <p>
  280. The <a href="lrs.html">LRS tutorial</a> explains further details.
  281. <h3>Interpolation and approximation</h3>
  282. Some of the vector modules deal with spatial or volumetric
  283. approximation (also called interpolation):
  284. <a href="v.kernel.html">v.kernel</a>,
  285. <a href="v.surf.idw.html">v.surf.idw</a>,
  286. <a href="v.surf.rst.html">v.surf.rst</a>, and
  287. <a href="v.vol.rst.html">v.vol.rst</a>.
  288. <h3>Lidar data processing</h3>
  289. Lidar point clouds (first and last return) are imported from text files
  290. with <a href="v.in.ascii.html">v.in.ascii</a> or from LAS files with
  291. <a href="v.in.lidar.html"> v.in.lidar</a>. Both modules recognize the
  292. -b flag to not build topology. Outlier detection is done with
  293. <a href="v.outlier.html">v.outlier</a> on both first and last return data.
  294. Then, with <a href="v.lidar.edgedetection.html">v.lidar.edgedetection</a>,
  295. edges are detected from last return data. The building are generated by
  296. <a href="v.lidar.growing.html">v.lidar.growing</a> from detected
  297. edges. The resulting data are post-processed with
  298. <a href="v.lidar.correction.html">v.lidar.correction</a>. Finally, the
  299. DTM and DSM are generated with <a href="v.surf.bspline.html">v.surf.bspline</a>
  300. (DTM: uses the 'v.lidar.correction' output; DSM: uses last return output
  301. from outlier detection).
  302. <h3>See also</h3>
  303. <ul>
  304. <li><a href="rasterintro.html">Introduction into raster data processing</a></li>
  305. <li><a href="raster3dintro.html">Introduction into 3D raster data (voxel) processing</a></li>
  306. <li><a href="vectorintro.html">Introduction into vector data processing</a></li>
  307. <li><a href="imageryintro.html">Introduction into image processing</a></li>
  308. <li><a href="databaseintro.html">Database management</a></li>
  309. <li><a href="projectionintro.html">Projections and spatial transformations</a></li>
  310. </ul>