1vectorintro(1)                Grass User's Manual               vectorintro(1)
2
3
4

Vector data processing in GRASS GIS

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
15   Attribute management
16       The  default  database  driver used by GRASS GIS 7 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
21       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
24   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
37       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
41       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
45   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
52   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
55       region beforehand (v.in.region, v.overlay, v.select).
56
57   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
69       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
78       In GRASS, the following vector object types are defined:
79
80           ·   point: a point;
81
82           ·   line:  a  directed sequence of connected vertices with two end‐
83               points called nodes;
84
85           ·   boundary: the border line to describe an area;
86
87           ·   centroid: a point within a closed ring of boundaries;
88
89           ·   area: the topological composition of a closed  ring  of  bound‐
90               aries and a centroid;
91
92           ·   face: a 3D area;
93
94           ·   kernel: a 3D centroid in a volume (not yet implemented);
95
96           ·   volume:  a  3D corpus, the topological composition of faces and
97               kernel (not yet implemented).
98
99       Lines and boundaries can be composed of multiple vertices.
100
101       Area topology also holds  information  about  isles.  These  isles  are
102       located  within  that  area,  not  touching the boundaries of the outer
103       area. Isles are holes inside the area, and can consist of one  or  more
104       areas. They are used internally to maintain correct topology for areas.
105
106       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
108       allows  the  user  to  extract erroneous vector objects into a separate
109       map. Topological errors can be corrected either manually  within  wxGUI
110       vector digitizer or, to some extent, automatically in v.clean.  A dedi‐
111       cated vector editing module is v.edit which supports global  and  local
112       editing  operations.   Adjacent  polygons  can be found by v.to.db (see
113       ’sides’ option).
114
115       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
126   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
129       attribute  management,  while  the v.db.* set of commands operates on a
130       table linked to a vector map.
131
132           ·   Categories
133               Categories are used  to  categorize  vector  objects  and  link
134               attribute(s)  to  each  category.  Each  vector object can have
135               zero, one or several categories. Category numbers do  not  have
136               to be unique for each vector object, several vector objects can
137               share 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
148           ·   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
157               series 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
183               entries  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
187               default. Using layer=-1 one can access all layers.
188
189           ·   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
206   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
211   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
227   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
232   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
237   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
241       applied when reading an existing GRASS raster map.
242
243   Vector queries
244       Vector maps can be queried with v.what and v.what.vect.
245
246   Vector-Raster queries
247       Raster  values  can  be transferred to vector maps with v.what.rast and
248       v.rast.stats.
249
250   Vector network analysis
251       GRASS provides support for vector network analysis. The following algo‐
252       rithms are implemented:
253
254           ·   Network preparation and maintenance: v.net
255
256           ·   Shortest path: d.path and v.net.path
257
258           ·   Shortest path between all pairs of nodes v.net.allpairs
259
260           ·   Allocation  of sources (create subnetworks, e.g. police station
261               zones): v.net.alloc
262
263           ·   Iso-distances (from centers): v.net.iso
264
265           ·   Computes bridges and articulation points: v.net.bridge
266
267           ·   Computes degree, centrality, betweeness, closeness  and  eigen‐
268               vector centrality measures: v.net.centrality
269
270           ·   Computes strongly and weakly connected components: v.net.compo‐
271               nents
272
273           ·   Computes  vertex  connectivity  between  two  sets  of   nodes:
274               v.net.connectivity
275
276           ·   Computes  shortest  distance  via the network between the given
277               sets of features: v.net.distance
278
279           ·   Computes the maximum flow between two sets of nodes: v.net.flow
280
281           ·   Computes minimum spanning tree:v.net.spanningtree
282
283           ·   Minimum Steiner trees (star-like  connections,  e.g.  broadband
284               cable connections): v.net.steiner
285
286           ·   Finds shortest path using timetables: v.net.timetable
287
288           ·   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
293   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
301       The LRS tutorial explains further details.
302
303   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
308   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
313       v.lidar.edgedetection, edges are detected from last  return  data.  The
314       building  are  generated  by  v.lidar.growing from detected edges.  The
315       resulting data are post-processed with v.lidar.correction. Finally, the
316       DTM   and   DSM  are  generated  with  v.surf.bspline  (DTM:  uses  the
317       ’v.lidar.correction’ output; DSM: uses last return output from  outlier
318       detection).
319       In addition, v.decimate can be used to decimates a point cloud.
320
321   See also
322           ·   Introduction to raster data processing
323
324           ·   Introduction to 3D raster data (voxel) processing
325
326           ·   Introduction to image processing
327
328           ·   Introduction into temporal data processing
329
330           ·   Introduction to database management
331
332           ·   Projections and spatial transformations
333

SOURCE CODE

335       Available at: Vector data processing in GRASS GIS source code (history)
336
337       Main  index  | Vector index | Topics index | Keywords index | Graphical
338       index | Full index
339
340       © 2003-2019 GRASS Development Team, GRASS GIS 7.8.2 Reference Manual
341
342
343
344GRASS 7.8.2                                                     vectorintro(1)
Impressum