1vectorintro(1) Grass User's Manual vectorintro(1)
2
6 Vector data 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 Metadata
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 Each map generating command stores the command history into the meta‐
22 data (query with v.info -h mapname). Metadata such as map title,
23 scale, organization etc. can be updated with v.support.
24 Vector map operations
26 GRASS vector map processing is always performed on the full map. If
27 this is not desired, the input map has to be clipped to the current
28 region beforehand (v.in.region, v.select).
29 Vector model and topology
31 GRASS is a topological GIS. This means that adjacent geographic compo‐
32 nents in a single vector map are related. For example in a non-topolog‐
33 ical GIS if two areas shared a common border that border would be digi‐
34 tized two times and also stored in duplicate. In a topological GIS this
35 border exists once and is shared between two areas. Topological repre‐
36 senation of vector data helps to produce and maintain vector maps with
37 clean geometry as well as enables certain analyses that can not be con‐
38 ducted with non-topological or spaghetti data. In GRASS topological
39 data are refered to as level 2 data and spaghetti data is referred to
40 as level 1.
41 Sometimes topology is not necessary and the additional memory and space
43 requirements are burdensome to a particular task. Therefore two modules
44 allow for working level 1 (non-topological) data within GRASS. The
45 v.in.ascii module allows users to input points without building topol‐
46 ogy. This is very useful for large files where memory restrictions may
47 cause difficulties. The other module which works with level 1 data is
48 v.surf.rst which enables spatial approximation and topographic analysis
49 from a point or isoline file.
50 In GRASS, the following vector objects are defined:
52 point: a point;
54 line: a directed sequence of connected vertices with two
56 endpoints called nodes;
57 boundary: the border line to describe an area;
59 centroid: a point within a closed boundary;
61 area: the topological composition of centroid and bound‐
63 ary;
64 face: a 3D area;
66 kernel: a 3D centroid in a volume (not yet implemented);
68 volume: a 3D corpus, the topological composition of
70 faces and kernel (not yet implemented).
71 Note that all lines and boundaries can be polylines (with nodes in
73 between).
74 The v.type module can be used to convert between vector types if possi‐
76 ble. The v.build module is used to generate topology. It optionally
77 allows to extract the erroneous vector objects into a separate map.
78 Topological errors can be corrected either manually within v.digit or,
79 to some extent, automatically in v.clean. Adjacent polygons can be
80 found by v.to.db (see 'sides' option).
81 Many operations including extraction, queries, overlay, and export will
83 only act on features which have been assigned a category number. Typi‐
84 cally a centroid will hold the attribute data for the area between it
85 and its boundary. Boundaries are not typically given a category ID as
86 it would be ambiguous as to which area either side of it the attribute
87 data would belong to. An exception might be when the boundary between
88 two crop-fields is the center-line of a road, and the category informa‐
89 tion is an index to the road name. For everyday use boundaries and cen‐
90 troids can be treated as internal data types and the user can work
91 directly and more simply with the "area" meta-feature type.
92 Attribute management
94 GRASS can be linked to one or many database management systems (DBMS).
95 The db.* set of commands provides basic SQL support for attribute man‐
96 agement, while the v.db.* set of commands operates on the vector map.
97 Categories: The category number is the vector ID. It is
99 used to link attribute(s) to each vector object. A vector
100 object can have zero, one, two, or more categories. Cate‐
101 gory numbers are stored both within the geometry file and
102 within the attribute table(s) for each vector object
103 (usually the "cat" column). Using v.category, category
104 numbers can be printed or maintained. In order to link
105 one vector object to several attribute tables, several
106 category numbers per vector object are needed.
107 Layers: It is possible to link the geographic objects in
109 a vector map to one or more tables. Each link to a dis‐
110 tinct attribute table is called a layer. A link defines
111 which database driver, database and table is to be used.
112 Each category numbers in a geometry file corresponds to a
113 row in the attribute table (the linking column is usually
114 the "cat" key column). Using v.db.connect layers can be
115 listed or maintained.
116 GRASS layers do not contain any geographic objects, but
117 they consist of links to attribute tables in which vector
118 objects can have zero, one or more categories. If a vec‐
119 tor object has zero categories in a layer, then it does
120 not appear in that layer. In this fashion some vector
121 objects may appear in some layers but not in others. The
122 practical benefit of this system is that it allows place‐
123 ment of thematically distinct but topologically related
124 objects into a single map (e.g. forests and lakes). These
125 virtual layers are also useful for linking time series
126 attribute data to a series of locations that did not
127 change over time. By default the first layer is active,
128 i.e. the first table corresponds to the first layer. Fur‐
129 ther tables are linked to subsequent layers.
130 SQL support: The DBF driver provides only very limited
132 SQL support (as DBF is not an SQL DB) while the other
133 DBMS backends (such as PostgreSQL, MySQL etc) provide
134 full SQL support since the SQL commands are sent directly
135 to the DBMI. SQL commands can be directly executed with
136 db.execute, db.select and the other db.* modules.
137 When creating vector maps from scratch, in general an attribute table
138 must be created and the table must be populated with one row per cate‐
139 gory (using v.to.db). However, this can be performed in a single step
140 using v.db.addtable along with the definition of table column types.
141 Column adding and dropping can be done with v.db.addcol and v.db.drop‐
142 col. A table column can be renamed with v.db.renamecol. To drop a table
143 from a map, use v.db.droptable. Values in a table can be updated with
144 v.db.update. Tables can be joined with with v.db.join.
145 Editing vector attributes
147 To manually edit attributes of a table, the map has to be queried in
148 'edit mode' using d.what.vect. To bulk process attributes, it is rec‐
149 ommended to use SQL (db.execute).
150 Geometry operations
152 The module v.in.region saves the current region boundary into a vector
153 area. Split vector lines can be changes to polylines by v.build.poly‐
154 lines. Long lines can be split by v.split and v.segment. Buffer and
155 circles can be generated with v.buffer and v.parallel. v.generalize is
156 module for generalization of GRASS vector maps. 2D vector maps can be
157 changed to 3D using v.extrude. If needed, the spatial position of vec‐
158 tor points can be perturbed by v.perturb. The v.type command changes
159 between vector types (see list above). Projected vector maps can be
160 reprojected with v.proj. Unprojected maps can be geocoded with
161 v.transform. Triangulation and point-to-polygon conversions can be
162 done with <a href="v.delaunay.html">v.delaunay, v.hull, and v.voronoi.
163 The v.random command generated random points.
164 Vector overlays and selections
166 Geometric overlay of vector maps is done with v.patch, v.select,
167 depending on the combination of vector types. Vectors can be extracted
168 with v.extract and reclassified with v.reclass.
169 Vector statistics
171 Statistics can be generated by v.qcount, v.normal, and v.univar. Dis‐
172 tances between vector objects are calculated with v.distance.
173 Vector-Raster-DB conversion
175 The v.to.db transfers vector information into database tables. With
176 v.to.points, v.to.rast3 conversions are performed.
177 Vector queries
179 Vector maps can be queried with v.what and v.what.vect.
180 Vector-Raster queries
182 Raster values can be transferred to vector maps with v.what.rast and
183 v.rast.stats.
184 Vector network analysis
186 GRASS provides support for vector network analysis. The following algo‐
187 rithms are implemented:
188 Vector maintenance: v.net
190 Shortest path: d.path and v.net.path
192 Traveling salesman (round trip): v.net.salesman
194 Allocation of sources (create subnetworks, e.g. police
196 station zones): v.net.alloc
197 Minimum Steiner trees (star-like connections, e.g.
199 broadband cable connections): v.net.steiner
200 Iso-distances (from centers): v.net.iso
202 --b). Both directions are supported, network modules provide parame‐
203 ters to assign attribute columns to the forward and backward direction.
204 Vector networks: Linear referencing system (LRS)
206 LRS uses linear features and distance measured along those features to
207 positionate objects. There are the commands v.lrs.create to create a
208 linear reference system, v.lrs.label to create stationing on the LRS,
209 v.lrs.segment to create points/segments on LRS, and v.lrs.where to find
210 line id and real km+offset for given points in vector map using linear
211 reference system.
212 The LRS tutorial explains further details.
214 Interpolation and approximation
216 Some of the vector modules deal with spatial or volumetric approxima‐
217 tion (also called interpolation): v.kernel, v.surf.idw, v.surf.rst, and
218 v.vol.rst.
219 Lidar data processing
221 Lidar point clouds (first and last return) are imported with <a
222 href="v.in.ascii.html">v.in.ascii (-b flag to not build the topology).
223 Outlier detection is done with v.outlier on both first and last return
224 data. Then, with v.lidar.edgedetection, edges are detected from last
225 return data. The building are generated by v.lidar.growing from
226 detected edges. The resulting data are post-processed with
227 v.lidar.correction. Finally, the DTM and DSM are generated with
228 v.surf.bspline (DTM: uses the 'v.lidar.correction' output; DSM: uses
229 last return output from outlier detection).
230 See also
232 Introduction to GRASS database management
233 Introduction to GRASS raster map processing
235 Introduction to GRASS 3D raster map (voxel) processing
237 full index
238GRASS 6.3.0 vectorintro(1)