1vectorintro(1) Grass User's Manual vectorintro(1)
2
6 Vector import and export
7 The v.in.ogr module offers a common interface for many different vector
8 formats. Additionally, it offers options such as on-the-fly creation of
9 new locations or extension of the default region to match the extent of
10 the imported vector map. For special cases, other import modules are
11 available, e.g. v.in.ascii for input from a text file containing coor‐
12 dinate and attribute data, and v.in.db for input from a database con‐
13 taining coordinate and attribute data. With v.external external maps
14 can be virtually linked into a mapset, only pseudo-topology is gener‐
15 ated but the vector geometry is not imported. The v.out.* set of com‐
16 mands exports to various formats.
17 Information
19 The v.info display general information such as metadata and attribute
20 columns about a vector map including the history how it was generated.
21 Vector map operations
23 GRASS vector map processing is always performed on the full map. If
24 this is not desired, the input map has to be clipped to the current
25 region beforehand (v.in.region, v.select).
26 Vector model and topology
28 GRASS is a topological GIS. This means that adjacent geographic compo‐
29 nents in a single vector map are related. For example in a non-topolog‐
30 ical GIS if two areas shared a common border that border would be digi‐
31 tized two times and also stored in duplicate. In a topological GIS this
32 border exists once and is shared between two areas. Topological repre‐
33 senation of vector data helps to produce and maintain vector maps with
34 clean geometry as well as enables certain analyses that can not be con‐
35 ducted with non-topological or spaghetti data. In GRASS topological
36 data are refered to as level 2 data and spaghetti data is referred to
37 as level 1.
38 Sometimes topology is not necessary and the additional memory and space
40 requirements are burdensome to a particular task. Therefore two modules
41 allow for working level 1 (non-topological) data within GRASS. The
42 v.in.ascii module allows users to input points without building topol‐
43 ogy. This is very useful for large files where memory restrictions may
44 cause difficulties. The other module which works with level 1 data is
45 v.surf.rst which enables spatial approximation and topographic analysis
46 from a point or isoline file.
47 In GRASS, the following vector objects are defined: point: a point;
49 line: a directed sequence of connected vertices with two endpoints
50 called nodes; boundary: the border line to describe an area; centroid:
51 a point within a closed boundary; area: the topological composition of
52 centroid and boundary; face: a 3D area; kernel: a 3D centroid in a vol‐
53 ume (not yet implemented); volume: a 3D corpus, the topological compo‐
54 sition of faces and kernel (not yet implemented).
55Note that all lines and boundaries can be polylines (with nodes in between).
57The v.type module can be used to convert between vector types if possible. The
59v.build module is used to generate topology. It optionally allows to extract
60the erroneous vector objects into a separate map. Topological errors can be
61corrected either manually within v.digit or, to some extent, automatically in
62v.clean. Adjacent polygons can be found by v.to.db (see 'sides' option).
63 Attribute management
65 GRASS can be linked to one or many database management systems (DBMS).
66 The db.* set of commands provides basic SQL support for attribute man‐
67 agement, while the v.db.* set of commands operates on the vector map.
68 Categories: The category number is the vector ID. It is
70 used to link attribute(s) to each vector object. A vector
71 object can have zero, one, two, or more categories. Cate‐
72 gory numbers are stored both within the geometry file and
73 within the attribute table(s) for each vector object
74 (usually the "cat" column). Using v.category, category
75 numbers can be printed or maintained. In order to link
76 one vector object to several attribute tables, several
77 category numbers per vector object are needed.
78 Layers: It is possible to link the geographic objects in
80 a vector map to one or more tables. Each link to a dis‐
81 tinct attribute table is called a layer. A link defines
82 which database driver, database and table is to be used.
83 Each category numbers in a geometry file corresponds to a
84 row in the attribute table (the linking column is usually
85 the "cat" key column). Using v.db.connect layers can be
86 listed or maintained.
87 GRASS layers do not contain any geographic objects, but
88 they consist of links to attribute tables in which vector
89 objects can have zero, one or more categories. If a vec‐
90 tor object has zero categories in a layer, then it does
91 not appear in that layer. In this fashion some vector
92 objects may appear in some layers but not in others. The
93 practical benefit of this system is that it allows place‐
94 ment of thematically distinct but topologically related
95 objects into a single map (e.g. forests and lakes). These
96 virtual layers are also useful for linking time series
97 attribute data to a series of locations that did not
98 change over time. By default the first layer is active,
99 i.e. the first table corresponds to the first layer. Fur‐
100 ther tables are linked to subsequent layers.
101 SQL support: The DBF driver provides only very limited
103 SQL support (as DBF is not an SQL DB) while the other
104 DBMS backends (such as PostgreSQL, MySQL etc) provide
105 full SQL support since the SQL commands are sent directly
106 to the DBMI. SQL commands can be directly executed with
107 db.execute, db.select and the other db.* modules.
108 When creating vector maps from scratch, in general an attribute table
109 must be created and the table must be populated with one row per cate‐
110 gory (using v.to.db). However, this can be performed in a single step
111 using v.db.addtable along with the definition of table column types.
112 Editing vector attributes
114 To manually edit attributes of a table, the map has to be queried in
115 'edit mode' using d.what.vect. To bulk process attributes, it is rec‐
116 ommended to use SQL (db.execute).
117 Geometry operations
119 The module v.in.region saves the current region boundary into a vector
120 area. Split vector lines can be changes to polylines by v.build.poly‐
121 lines. Long lines can be split by v.split and v.segment. Buffer and
122 circles can be generated with v.buffer and v.parallel. 2D vector maps
123 can be changed to 3D using v.extrude. If needed, the spatial position
124 of vector points can be perturbed by v.perturb. The v.type command
125 changes between vector types (see list above). Projected vector maps
126 can be reprojected with v.proj. Unprojected maps can be geocoded with
127 v.transform. Triangulation and point-to-polygon conversions can be
128 done with <a href="v.delaunay.html">v.delaunay, v.hull, and v.voronoi.
129 The v.random command generated random points.
130 Vector overlays and selections
132 Geometric overlay of vector maps is done with v.patch, v.select,
133 depending on the combination of vector types. Vectors can be extracted
134 with v.extract and reclassified with v.reclass.
135 Vector statistics
137 Statistics can be generated by v.qcount, v.normal, and v.univar. Dis‐
138 tances between vector objects are calculated with v.distance.
139 Vector-Raster-DB conversion
141 The v.to.db transfers vector information into database tables. With
142 v.to.points, v.to.rast3 conversions are performed.
143 Vector queries
145 Vector maps can be queried with v.what and v.what.vect.
146 Vector-Raster queries
148 Raster values can be transferred to vector maps with v.what.rast and
149 v.rast.stats.
150 Vector network analysis
152 GRASS provides support for vector network analysis. The following algo‐
153 rithms are implemented:
154 Vector maintenance: v.net
156 Shortest path: d.path and v.net.path
158 Traveling salesman (round trip): v.net.salesman
160 Allocation of sources (create subnetworks, e.g. police
162 station zones): v.net.alloc
163 Minimum Steiner trees (star-like connections, e.g.
165 broadband cable connections): v.net.steiner
166 Iso-distances (from centers): v.net.iso
168 --b). Both directions are supported, network modules provide parame‐
169 ters to assign attribute columns to the forward and backward direction.
170 Vector networks: Linear reference system (LRS)
172 LRS uses linear features and distance measured along those features to
173 positionate objects. There are the commands v.lrs.create to create a
174 linear reference system, v.lrs.label to create stationing on the LRS,
175 v.lrs.segment to create points/segments on LRS, and v.lrs.where to find
176 line id and real km+offset for given points in vector map using linear
177 reference system.
178 The LRS tutorial explains further details.
180 Interpolation and approximation
182 Some of the vector modules deal with spatial or volumetric approxima‐
183 tion (also called interpolation): v.kernel, v.surf.idw, v.surf.rst, and
184 v.vol.rst.
185 Lidar data processing
187 Lidar point clouds (first and last ping) are imported with <a
188 href="v.in.ascii.html">v.in.ascii (-b flag to not build the topology).
189 Outlier detection is done with v.outlier on both first and last ping
190 data. Then, with v.lidar.edgedetection, edges are detected from last
191 ping data. The building are generated by v.lidar.growing from detected
192 edges. The resulting data are post-processed with v.lidar.correction.
193 Finally, the DTM and DSM are generated with v.surf.bspline (DTM: uses
194 the 'v.lidar.correction' output; DSM: uses last ping output from out‐
195 lier detection).
196 See also
198 Introduction to GRASS database management
199 Introduction to GRASS raster map processing
201 Introduction to GRASS 3D raster map (voxel) processing
203 full index
204GRASS 6.2.2 vectorintro(1)