Note: A new GRASS GIS stable version has been released: GRASS GIS 7.8, available here.
Updated manual page: here
Vector data processing in GRASS GIS
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.
The default database driver used by GRASS GIS 7 is SQLite. GRASS GIS
handles multiattribute vector data by default. The db.*
commands provides basic SQL support for attribute management, while the
set of commands operates on vector maps.
Note: The list of available database drivers can vary in various binary
distributions of GRASS GIS, for details see
SQL support in GRASS GIS.
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.
for input from a text file
containing coordinate and attribute data, and
for input from a database containing
coordinate and attribute data.
external maps can be
virtually linked into a mapset, only pseudo-topology is generated but
the vector geometry is not imported.
set of commands exports to various formats. To import
and export only attribute tables, use db.in.ogr
GRASS GIS vector map exchange between different locations (same projection)
can be done in a lossless way using the v.pack
and v.unpack modules.
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_]*).
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
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
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 representation 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 referred 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 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).
Lines and boundaries can be composed of multiple vertices.
Area topology also holds information about isles. These isles are located
within that area, not touching the boundaries of the outer area. Isles
are holes inside the area, and can consist of one or more areas. They 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 the user to extract erroneous
vector objects into a separate map. Topological errors can be
corrected either manually
within wxGUI vector digitizer or,
to some extent, automatically in v.clean.
A dedicated vector editing module is v.edit
which supports global and local editing operations.
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 with which the centroid is
associated. 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"
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 (optional) 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.
Layers are a characteristic of the vector feature (geometries) file.
As mentioned above, categories allow the user to give either a
unique id to each feature or to group similar features by giving
them all the same id. Layers allow several parallel, but different
groupings of features in a same map. The practical benefit of this
system is that it allows placement of thematically distinct but
topologically related objects into a single map, or for linking time
series attribute data to a series of locations that did not change
For example, one can have roads with one layer
containing the unique id of each road and another layer with ids for
specific routes that one might take, combining several roads by
assigning the same id. While this example can also be dealt with in
an attribute table, another example of the use of layers that shows
their specific advantage is the possibility to identify the same geometrical
features as representing different thematic objects. For example,
in a map with a series of polygons representing fields in
which at the same time the boundaries of these fields have a meaning
as linear features, e.g. as paths, one can give a unique id to each
field as area in layer 1, and a unique id in layer 2 to those
boundary lines that are paths. If the paths will always depend on
the field boundaries (and might change if these boundaries
change) then keeping them in the same map can be helpful. Trying
to reproduce the same functionality through attributes is much more
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. Taking the example of the fields
and paths, only some boundaries, but not all, might have a category
value in layer 2. With option=report,
v.category lists available categories
in each layer.
Optionally, each layer can (but does not have
to) be linked to an attribute table. The link is made by the
category values of the features in that layer which have to have
corresponding entries in the specified key column of the table.
Using v.db.connect connections
between layers and attribute tables can be listed or maintained.
In most modules, the first layer (layer=1) is active by
default. Using layer=-1 one can access all layers.
- SQL support
By default, SQLite is used as the attribute database. Also other
supported DBMS backends (such as SQLite, PostgreSQL, MySQL etc.)
provide full SQL support as the SQL statements are sent directly
to GRASS' database management interface (DBMI). Only the DBF driver
provides just very limited SQL support (as DBF is not an SQL DB).
SQL commands can be directly executed with
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.addcolumn
. A table column can be renamed with
. To drop a table from a map, use
. Values in a table can be updated
. Tables can be joined with with
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
The module v.in.region
current region extents as a vector area.
Split vector lines can be converted to polylines by
. Long lines can be
split by v.split
Buffer and circles can be generated with v.buffer
is module for generalization of GRASS vector maps.
2D vector maps can be changed to 3D using
If needed, the spatial position of vector points can be perturbed by
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
Based on the control points, v.rectify
vector map by computing a coordinate transformation for each vector object.
Triangulation and point-to-polygon conversions can be done with v.delaunay
command generated random points.
Geometric overlay of vector maps is done with v.patch
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
, and v.vect.stats
Distances between vector objects are calculated with v.distance
transfers vector information
into database tables.
conversions are performed. Note that a raster mask ("MASK") will not be
respected since it is only applied when reading
GRASS raster map.
Vector maps can be queried with v.what
Raster values can be transferred to vector maps with
GRASS provides support for vector network analysis. The following algorithms
Vector directions are defined by the digitizing direction (a-->--b).
Both directions are supported, most network modules provide parameters
to assign attribute columns to the forward and backward direction.
LRS uses linear features and distance measured along those features to
positionate objects. There are the commands
to create a linear reference system,
to create stationing on the LRS,
to create points/segments on LRS,
to find line id and real km+offset
for given points in vector map using linear reference system.
The LRS tutorial explains further details.
Some of the vector modules deal with spatial or volumetric
approximation (also called interpolation):
Lidar point clouds (first and last return) are imported from text files
or from LAS files with
. Both modules recognize the
-b flag to not build topology. Outlier detection is done with
on both first and last return data.
Then, with v.lidar.edgedetection
edges are detected from last return data. The building are generated by
edges. The resulting data are post-processed with
. 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).
In addition, v.decimate
can be used to decimates
a point cloud.
Available at: Vector data processing in GRASS GIS source code (history)
Note: A new GRASS GIS stable version has been released: GRASS GIS 7.8, available here.
Updated manual page: here
Main index |
Vector index |
Topics index |
Keywords index |
Graphical index |
GRASS Development Team,
GRASS GIS 7.6.2dev Reference Manual