Homepage > Man Pages > Category > General Commands
Homepage > Man Pages > Name > V
man page of vectorintro
vectorintro: Vector data processing
vectorintro - Vector data processing
Vector data processing
VECTOR DATA PROCESSING IN GRASS GIS
Vector maps in general
A "vector map" is a data layer consisting of a number of sparse
features in geographic space. These might be data points (drill sites),
lines (roads), polygons (park boundary), volumes (3D CAD structure), or
some combination of all these. Typically each feature in the map will
be tied to a set of attribute layers stored in a database (road names,
site ID, geologic type, etc.). As a general rule these can exist in 2D
or 3D space and are independent of the GIS's computation region.
Vector data import and export
The v.in.ogr module offers a common interface for many different vector
formats. Additionally, it offers options such as on-the-fly creation of
new locations or extension of the default region to match the extent of
the imported vector map. For special cases, other import modules are
available, e.g. v.in.ascii for input from a text file containing
coordinate and attribute data, and v.in.db for input from a database
containing coordinate and attribute data. With v.external external
maps can be virtually linked into a mapset, only pseudo-topology is
generated but the vector geometry is not imported. The v.out.* set of
commands exports to various formats. To import and export only
attribute tables, use db.in.ogr and db.out.ogr. The naming convention
for vector maps requires that map names start with a character, not a
number (map name scheme: [A-Za-z][A-Za-z0-9_]*).
The v.info display general information such as metadata and attribute
columns about a vector map including the history how it was generated.
Each map generating command stores the command history into the
metadata (query with v.info -h mapname). Metadata such as map title,
scale, organization etc. can be updated with v.support.
Vector map operations
GRASS vector map processing is always performed on the full map. If
this is not desired, the input map has to be clipped to the current
region beforehand (v.in.region, v.select).
Vector model and topology
GRASS is a topological GIS. This means that adjacent geographic
components in a single vector map are related. For example in a non-
topological GIS if two areas shared a common border that border would
be digitized two times and also stored in duplicate. In a topological
GIS this border exists once and is shared between two areas.
Topological represenation of vector data helps to produce and maintain
vector maps with clean geometry as well as enables certain analyses
that can not be conducted with non-topological or spaghetti data. In
GRASS topological data are refered to as level 2 data and spaghetti
data is referred to as level 1.
Sometimes topology is not necessary and the additional memory and space
requirements are burdensome to a particular task. Therefore two modules
allow for working level 1 (non-topological) data within GRASS. The
v.in.ascii module allows users to input points without building
topology. This is very useful for large files where memory restrictions
may cause difficulties. The other module which works with level 1 data
is v.surf.rst which enables spatial approximation and topographic
analysis from a point or isoline file.
In GRASS, the following vector object types are defined:
point: a point;
line: a directed sequence of connected vertices with two
endpoints called nodes;
boundary: the border line to describe an area;
centroid: a point within a closed ring of boundaries;
area: the topological composition of a closed ring of
boundaries and optionally a centroid;
face: a 3D area;
kernel: a 3D centroid in a volume (not yet implemented);
volume: a 3D corpus, the topological composition of
faces and kernel (not yet implemented).
Note that all lines and boundaries can be polylines (with vertices in
Area topology also holds information about isles. These isles are
located within that area, not touching the boundaries of the outer
area. Isles consist of one or more areas and are used internally to
maintain correct topology for areas.
The v.type module can be used to convert between vector types if
possible. The v.build module is used to generate topology. It
optionally allows to extract the erroneous vector objects into a
separate map. Topological errors can be corrected either manually
within v.digit or, to some extent, automatically in v.clean. A
dedicated vector editing module is v.edit which supports global and
local editing operations. Additionally, new advanced topological
operations are available in the new digitizing tool. Adjacent polygons
can be found by v.to.db (see 'sides' option).
Many operations including extraction, queries, overlay, and export will
only act on features which have been assigned a category number.
Typically a centroid will hold the attribute data for the area between
it and its boundaries. Boundaries are not typically given a category ID
as it would be ambiguous as to which area either side of it the
attribute data would belong to. An exception might be when the boundary
between two crop-fields is the center-line of a road, and the category
information is an index to the road name. For everyday use boundaries
and centroids can be treated as internal data types and the user can
work directly and more simply with the "area" meta-feature type.
Vector object categories and attribute management
GRASS vectors can be linked to one or many database management systems
(DBMS). The db.* set of commands provides basic SQL support for
attribute management, while the v.db.* set of commands operates on a
table linked to a vector map.
Categories are used to categorize vector objects and link
attribute(s) to each category. Each vector object can
have zero, one or several categories. Category numbers do
not have to be unique for each vector object, several
vector objects can share the same category.
Category numbers are stored both within the geometry file
for each vector object and within the attribute table(s)
(usually the "cat" column). It is not required that
attribute table(s) hold an entry for each category, and
attribute table(s) can hold information about categories
not present in the vector geometry file. This means that
e.g. an attribute table can be populated first and then
vector objects can be added to the geometry file with
category numbers. Using v.category, category numbers can
be printed or maintained.
It is possible to link the geographic objects in a vector
map to one or more tables. Each link to a distinct
attribute table is called a layer. A link defines which
database driver, database and table is to be used. Each
category number in a geometry file is associated with a
layer and corresponds to a row in the attribute table for
this layer (the linking column is usually the "cat" key
column). Using v.db.connect layers can be listed or
Vector objects are not organized in layers. All vector
objects are kept in one geometry file, and topology is
maintained for all vector objects together. GRASS layers
only consist of links to different attribute tables in
which vector objects can have zero, one or more
categories. If a vector object has zero categories in a
layer, then it does not appear in that layer. In this
fashion some vector objects may appear in some layers but
not in others. The practical benefit of this system is
that it allows placement of thematically distinct but
topologically related objects into a single map (e.g.
forests and lakes). These virtual layers are also useful
for linking time series attribute data to a series of
locations that did not change over time. By default the
first layer is active, i.e. the first table corresponds
to the first layer. Further tables are linked to
The DBF driver provides only very limited SQL support (as
DBF is not an SQL DB) while the other DBMS backends (such
as SQLite, PostgreSQL, MySQL etc) provide full SQL
support since the SQL commands are sent directly to the
DBMI. SQL commands can be directly executed with
db.execute, db.select and the other db.* modules.
When creating vector maps from scratch, in general an attribute table
must be created and the table must be populated with one row per
category (using v.to.db). However, this can be performed in a single
step using v.db.addtable along with the definition of table column
types. Column adding and dropping can be done with v.db.addcol and
v.db.dropcol. A table column can be renamed with v.db.renamecol. To
drop a table from a map, use v.db.droptable. Values in a table can be
updated with v.db.update. Tables can be joined with with v.db.join.
Editing vector attributes
To manually edit attributes of a table, the map has to be queried in
'edit mode' using d.what.vect. To bulk process attributes, it is
recommended to use SQL (db.execute).
The module v.in.region saves the current region boundary into a vector
area. Split vector lines can be changes to polylines by
v.build.polylines. Long lines can be split by v.split and v.segment.
Buffer and circles can be generated with v.buffer and v.parallel.
v.generalize is module for generalization of GRASS vector maps. 2D
vector maps can be changed to 3D using v.extrude. If needed, the
spatial position of vector points can be perturbed by v.perturb. The
v.type command changes between vector types (see list above).
Projected vector maps can be reprojected with v.proj. Unprojected maps
can be geocoded with v.transform. Triangulation and point-to-polygon
conversions can be done with <a href="v.delaunay.html">v.delaunay,
v.hull, and v.voronoi. The v.random command generated random points.
Vector overlays and selections
Geometric overlay of vector maps is done with v.patch, v.select,
depending on the combination of vector types. Vectors can be extracted
with v.extract and reclassified with v.reclass.
Statistics can be generated by v.qcount, v.normal, and v.univar.
Distances between vector objects are calculated with v.distance.
The v.to.db transfers vector information into database tables. With
v.to.points, v.to.rast3 conversions are performed.
Vector maps can be queried with v.what and v.what.vect.
Raster values can be transferred to vector maps with v.what.rast and
Vector network analysis
GRASS provides support for vector network analysis. The following
algorithms are implemented:
Vector maintenance: v.net
Shortest path: d.path and v.net.path
Traveling salesman (round trip): v.net.salesman
Allocation of sources (create subnetworks, e.g. police
station zones): v.net.alloc
Minimum Steiner trees (star-like connections, e.g.
broadband cable connections): v.net.steiner
Iso-distances (from centers): v.net.iso
--b). Both directions are supported, network modules provide
parameters to assign attribute columns to the forward and backward
Vector networks: Linear referencing system (LRS)
LRS uses linear features and distance measured along those features to
positionate objects. There are the commands v.lrs.create to create a
linear reference system, v.lrs.label to create stationing on the LRS,
v.lrs.segment to create points/segments on LRS, and v.lrs.where to find
line id and real km+offset for given points in vector map using linear
The LRS tutorial explains further details.
Interpolation and approximation
Some of the vector modules deal with spatial or volumetric
approximation (also called interpolation): v.kernel, v.surf.idw,
v.surf.rst, and v.vol.rst.
Lidar data processing
Lidar point clouds (first and last return) are imported with <a
href="v.in.ascii.html">v.in.ascii (-b flag to not build the topology).
Outlier detection is done with v.outlier on both first and last return
data. Then, with v.lidar.edgedetection, edges are detected from last
return data. The building are generated by v.lidar.growing from
detected edges. The resulting data are post-processed with
v.lidar.correction. Finally, the DTM and DSM are generated with
v.surf.bspline (DTM: uses the 'v.lidar.correction' output; DSM: uses
last return output from outlier detection).
Introduction to GRASS database management
Introduction to GRASS raster map processing
Introduction to GRASS 3D raster map (voxel) processing
(C) 2008 GRASS Development Team