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