1vectorintro(1) GRASS GIS User's Manual vectorintro(1)
2
6 Vector maps in general
7 A "vector map" is a data layer consisting of a number of sparse fea‐
8 tures in geographic space. These might be data points (drill sites),
9 lines (roads), polygons (park boundary), volumes (3D CAD structure), or
10 some combination of all these. Typically each feature in the map will
11 be tied to a set of attribute layers stored in a database (road names,
12 site ID, geologic type, etc.). As a general rule these can exist in 2D
13 or 3D space and are independent of the GIS’s computation region.
14 Attribute management
16 The default database driver used by GRASS GIS 8 is SQLite. GRASS GIS
17 handles multiattribute vector data by default. The db.* set of commands
18 provides basic SQL support for attribute management, while the v.db.*
19 set of commands operates on vector maps.
20 Note: The list of available database drivers can vary in various binary
22 distributions of GRASS GIS, for details see SQL support in GRASS GIS.
23 Vector data import and export
25 The v.in.ogr module offers a common interface for many different vector
26 formats. Additionally, it offers options such as on-the-fly creation of
27 new locations or extension of the default region to match the extent of
28 the imported vector map. For special cases, other import modules are
29 available, e.g. v.in.ascii for input from a text file containing coor‐
30 dinate and attribute data, and v.in.db for input from a database con‐
31 taining coordinate and attribute data. With v.external external maps
32 can be virtually linked into a mapset, only pseudo-topology is gener‐
33 ated but the vector geometry is not imported. The v.out.* set of com‐
34 mands exports to various formats. To import and export only attribute
35 tables, use db.in.ogr and db.out.ogr.
36 GRASS GIS vector map exchange between different locations (same projec‐
38 tion) can be done in a lossless way using the v.pack and v.unpack mod‐
39 ules.
40 The naming convention for vector maps requires that map names start
42 with a character, not a number (map name scheme:
43 [A-Za-z][A-Za-z0-9_]*).
44 Metadata
46 The v.info display general information such as metadata and attribute
47 columns about a vector map including the history how it was generated.
48 Each map generating command stores the command history into the meta‐
49 data (query with v.info -h mapname). Metadata such as map title,
50 scale, organization etc. can be updated with v.support.
51 Vector map operations
53 GRASS vector map processing is always performed on the full map. If
54 this is not desired, the input map has to be clipped to the current re‐
55 gion beforehand (v.in.region, v.overlay, v.select).
56 Vector model and topology
58 GRASS is a topological GIS. This means that adjacent geographic compo‐
59 nents in a single vector map are related. For example in a non-topolog‐
60 ical GIS if two areas shared a common border that border would be digi‐
61 tized two times and also stored in duplicate. In a topological GIS this
62 border exists once and is shared between two areas. Topological repre‐
63 sentation of vector data helps to produce and maintain vector maps with
64 clean geometry as well as enables certain analyses that can not be con‐
65 ducted with non-topological or spaghetti data. In GRASS, topological
66 data are referred to as level 2 data and spaghetti data is referred to
67 as level 1.
68 Sometimes topology is not necessary and the additional memory and space
70 requirements are burdensome to a particular task. Therefore two modules
71 allow for working level 1 (non-topological) data within GRASS. The
72 v.in.ascii module allows users to input points without building topol‐
73 ogy. This is very useful for large files where memory restrictions may
74 cause difficulties. The other module which works with level 1 data is
75 v.surf.rst which enables spatial approximation and topographic analysis
76 from a point or isoline file.
77 In GRASS, the following vector object types are defined:
79 • point: a point;
81 • line: a directed sequence of connected vertices with two end‐
83 points called nodes;
84 • boundary: the border line to describe an area;
86 • centroid: a point within a closed ring of boundaries;
88 • area: the topological composition of a closed ring of bound‐
90 aries and a centroid;
91 • face: a 3D area;
93 • kernel: a 3D centroid in a volume (not yet implemented);
95 • volume: a 3D corpus, the topological composition of faces and
97 kernel (not yet implemented).
98 Lines and boundaries can be composed of multiple vertices.
100 Area topology also holds information about isles. These isles are lo‐
102 cated within that area, not touching the boundaries of the outer area.
103 Isles are holes inside the area, and can consist of one or more areas.
104 They are used internally to maintain correct topology for areas.
105 The v.type module can be used to convert between vector types if possi‐
107 ble. The v.build module is used to generate topology. It optionally al‐
108 lows the user to extract erroneous vector objects into a separate map.
109 Topological errors can be corrected either manually within wxGUI vector
110 digitizer or, to some extent, automatically in v.clean. A dedicated
111 vector editing module is v.edit which supports global and local editing
112 operations. Adjacent polygons can be found by v.to.db (see ’sides’ op‐
113 tion).
114 Many operations including extraction, queries, overlay, and export will
116 only act on features which have been assigned a category number. Typi‐
117 cally a centroid will hold the attribute data for the area with which
118 the centroid is associated. Boundaries are not typically given a cate‐
119 gory ID as it would be ambiguous as to which area either side of it the
120 attribute data would belong to. An exception might be when the boundary
121 between two crop-fields is the center-line of a road, and the category
122 information is an index to the road name. For everyday use boundaries
123 and centroids can be treated as internal data types and the user can
124 work directly and more simply with the "area" type.
125 Vector object categories and attribute management
127 GRASS vectors can be linked to one or many database management systems
128 (DBMS). The db.* set of commands provides basic SQL support for attri‐
129 bute management, while the v.db.* set of commands operates on a table
130 linked to a vector map.
131 • Categories
133 Categories are used to categorize vector objects and link at‐
134 tribute(s) to each category. Each vector object can have zero,
135 one or several categories. Category numbers do not have to be
136 unique for each vector object, several vector objects can share
137 the same category.
138 Category numbers are stored both within the geometry file for
139 each vector object and within the (optional) attribute table(s)
140 (usually the "cat" column). It is not required that attribute
141 table(s) hold an entry for each category, and attribute ta‐
142 ble(s) can hold information about categories not present in the
143 vector geometry file. This means that e.g. an attribute table
144 can be populated first and then vector objects can be added to
145 the geometry file with category numbers. Using v.category,
146 category numbers can be printed or maintained.
147 • Layers
149 Layers are a characteristic of the vector feature (geometries)
150 file. As mentioned above, categories allow the user to give
151 either a unique id to each feature or to group similar features
152 by giving them all the same id. Layers allow several parallel,
153 but different groupings of features in a same map. The practi‐
154 cal benefit of this system is that it allows placement of the‐
155 matically distinct but topologically related objects into a
156 single map, or for linking time series attribute data to a se‐
157 ries of locations that did not change over time.
158 For example, one can have roads with one layer containing the
159 unique id of each road and another layer with ids for specific
160 routes that one might take, combining several roads by assign‐
161 ing the same id. While this example can also be dealt with in
162 an attribute table, another example of the use of layers that
163 shows their specific advantage is the possibility to identify
164 the same geometrical features as representing different the‐
165 matic objects. For example, in a map with a series of polygons
166 representing fields in which at the same time the boundaries of
167 these fields have a meaning as linear features, e.g. as paths,
168 one can give a unique id to each field as area in layer 1, and
169 a unique id in layer 2 to those boundary lines that are paths.
170 If the paths will always depend on the field boundaries (and
171 might change if these boundaries change) then keeping them in
172 the same map can be helpful. Trying to reproduce the same func‐
173 tionality through attributes is much more complicated.
174 If a vector object has zero categories in a layer, then it does
175 not appear in that layer. In this fashion some vector objects
176 may appear in some layers but not in others. Taking the example
177 of the fields and paths, only some boundaries, but not all,
178 might have a category value in layer 2. With option=report,
179 v.category lists available categories in each layer.
180 Optionally, each layer can (but does not have to) be linked to
181 an attribute table. The link is made by the category values of
182 the features in that layer which have to have corresponding en‐
183 tries in the specified key column of the table. Using
184 v.db.connect connections between layers and attribute tables
185 can be listed or maintained.
186 In most modules, the first layer (layer=1) is active by de‐
187 fault. Using layer=-1 one can access all layers.
188 • SQL support
190 By default, SQLite is used as the attribute database. Also
191 other supported DBMS backends (such as SQLite, PostgreSQL,
192 MySQL etc.) provide full SQL support as the SQL statements are
193 sent directly to GRASS’ database management interface (DBMI).
194 Only the DBF driver provides just very limited SQL support (as
195 DBF is not an SQL DB). SQL commands can be directly executed
196 with db.execute, db.select and the other db.* modules.
197 When creating vector maps from scratch, in general an attribute table
198 must be created and the table must be populated with one row per cate‐
199 gory (using v.to.db). However, this can be performed in a single step
200 using v.db.addtable along with the definition of table column types.
201 Column adding and dropping can be done with v.db.addcolumn and
202 v.db.dropcolumn. A table column can be renamed with v.db.renamecolumn.
203 To drop a table from a map, use v.db.droptable. Values in a table can
204 be updated with v.db.update. Tables can be joined with with v.db.join.
205 Editing vector attributes
207 To manually edit attributes of a table, the map has to be queried in
208 ’edit mode’ using d.what.vect. To bulk process attributes, it is rec‐
209 ommended to use SQL (db.execute).
210 Geometry operations
212 The module v.in.region saves the current region extents as a vector
213 area. Split vector lines can be converted to polylines by
214 v.build.polylines. Long lines can be split by v.split and v.segment.
215 Buffer and circles can be generated with v.buffer and v.parallel.
216 v.generalize is module for generalization of GRASS vector maps. 2D
217 vector maps can be changed to 3D using v.drape or v.extrude. If
218 needed, the spatial position of vector points can be perturbed by
219 v.perturb. The v.type command changes between vector types (see list
220 above). Projected vector maps can be reprojected with v.proj. Unpro‐
221 jected maps can be geocoded with v.transform. Based on the control
222 points, v.rectify rectifies a vector map by computing a coordinate
223 transformation for each vector object. Triangulation and
224 point-to-polygon conversions can be done with v.delaunay, v.hull, and
225 v.voronoi. The v.random command generated random points.
226 Vector overlays and selections
228 Geometric overlay of vector maps is done with v.patch, v.overlay and
229 v.select, depending on the combination of vector types. Vectors can be
230 extracted with v.extract and reclassified with v.reclass.
231 Vector statistics
233 Statistics can be generated by v.qcount, v.sample, v.normal, v.univar,
234 and v.vect.stats. Distances between vector objects are calculated with
235 v.distance.
236 Vector-Raster-DB conversion
238 The v.to.db transfers vector information into database tables. With
239 v.to.points, v.to.rast and v.to.rast3 conversions are performed. Note
240 that a raster mask ("MASK") will not be respected since it is only ap‐
241 plied when reading an existing GRASS raster map.
242 Vector queries
244 Vector maps can be queried with v.what and v.what.vect.
245 Vector-Raster queries
247 Raster values can be transferred to vector maps with v.what.rast and
248 v.rast.stats.
249 Vector network analysis
251 GRASS provides support for vector network analysis. The following algo‐
252 rithms are implemented:
253 • Network preparation and maintenance: v.net
255 • Shortest path: d.path and v.net.path
257 • Shortest path between all pairs of nodes v.net.allpairs
259 • Allocation of sources (create subnetworks, e.g. police station
261 zones): v.net.alloc
262 • Iso-distances (from centers): v.net.iso
264 • Computes bridges and articulation points: v.net.bridge
266 • Computes degree, centrality, betweeness, closeness and eigen‐
268 vector centrality measures: v.net.centrality
269 • Computes strongly and weakly connected components: v.net.compo‐
271 nents
272 • Computes vertex connectivity between two sets of nodes:
274 v.net.connectivity
275 • Computes shortest distance via the network between the given
277 sets of features: v.net.distance
278 • Computes the maximum flow between two sets of nodes: v.net.flow
280 • Computes minimum spanning tree:v.net.spanningtree
282 • Minimum Steiner trees (star-like connections, e.g. broadband
284 cable connections): v.net.steiner
285 • Finds shortest path using timetables: v.net.timetable
287 • Traveling salesman (round trip): v.net.salesman
289 Vector directions are defined by the digitizing direction (a-->--b).
290 Both directions are supported, most network modules provide parameters
291 to assign attribute columns to the forward and backward direction.
292 Vector networks: Linear referencing system (LRS)
294 LRS uses linear features and distance measured along those features to
295 positionate objects. There are the commands v.lrs.create to create a
296 linear reference system, v.lrs.label to create stationing on the LRS,
297 v.lrs.segment to create points/segments on LRS, and v.lrs.where to find
298 line id and real km+offset for given points in vector map using linear
299 reference system.
300 The LRS tutorial explains further details.
302 Interpolation and approximation
304 Some of the vector modules deal with spatial or volumetric approxima‐
305 tion (also called interpolation): v.kernel, v.surf.idw, v.surf.rst, and
306 v.vol.rst.
307 Lidar data processing
309 Lidar point clouds (first and last return) are imported from text files
310 with v.in.ascii or from LAS files with v.in.lidar. Both modules recog‐
311 nize the -b flag to not build topology. Outlier detection is done with
312 v.outlier on both first and last return data. Then, with v.li‐
313 dar.edgedetection, edges are detected from last return data. The build‐
314 ing are generated by v.lidar.growing from detected edges. The result‐
315 ing data are post-processed with v.lidar.correction. Finally, the DTM
316 and DSM are generated with v.surf.bspline (DTM: uses the ’v.lidar.cor‐
317 rection’ output; DSM: uses last return output from outlier detection).
318 In addition, v.decimate can be used to decimates a point cloud.
319 See also
321 • Introduction to raster data processing
322 • Introduction to 3D raster data (voxel) processing
324 • Introduction to image processing
326 • Introduction into temporal data processing
328 • Introduction to database management
330 • Projections and spatial transformations
332
334 Available at: Vector data processing in GRASS GIS source code (history)
335 Accessed: Tuesday Oct 24 19:27:44 2023
337 Main index | Vector index | Topics index | Keywords index | Graphical
339 index | Full index
340 © 2003-2023 GRASS Development Team, GRASS GIS 8.3.1 Reference Manual
342GRASS 8.3.1 vectorintro(1)