vectorintro(1grass) GRASS GIS User's Manual vectorintro(1grass)
Vector data processing in GRASS GIS
Vector maps in general
A "vector map" is a data layer consisting of a number of sparse fea-
tures 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.
Attribute management
The default database driver used by GRASS GIS 7 is SQLite. GRASS GIS
handles multiattribute vector data by default. The db.* set of commands
provides basic SQL support for attribute management, while the v.db.*
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.
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 coor-
dinate and attribute data, and v.in.db for input from a database con-
taining coordinate and attribute data. With v.external external maps
can be virtually linked into a mapset, only pseudo-topology is gener-
ated but the vector geometry is not imported. The v.out.* set of com-
mands exports to various formats. To import and export only attribute
tables, use db.in.ogr and db.out.ogr.
GRASS GIS vector map exchange between different locations (same projec-
tion) can be done in a lossless way using the v.pack and v.unpack mod-
ules.
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_]*).
Metadata
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 meta-
data (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 re-
gion beforehand (v.in.region, v.overlay, v.select).
Vector model and topology
GRASS is a topological GIS. This means that adjacent geographic compo-
nents in a single vector map are related. For example in a non-topolog-
ical GIS if two areas shared a common border that border would be digi-
tized two times and also stored in duplicate. In a topological GIS this
border exists once and is shared between two areas. Topological repre-
sentation of vector data helps to produce and maintain vector maps with
clean geometry as well as enables certain analyses that can not be con-
ducted 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 topol-
ogy. 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 end-
points 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 bound-
aries 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 lo-
cated 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 possi-
ble. The v.build module is used to generate topology. It optionally al-
lows 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’ op-
tion).
Many operations including extraction, queries, overlay, and export will
only act on features which have been assigned a category number. Typi-
cally a centroid will hold the attribute data for the area with which
the centroid is associated. Boundaries are not typically given a cate-
gory 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" 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 attri-
bute management, while the v.db.* set of commands operates on a table
linked to a vector map.
• Categories
Categories are used to categorize vector objects and link at-
tribute(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 ta-
ble(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
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 practi-
cal benefit of this system is that it allows placement of the-
matically distinct but topologically related objects into a
single map, or for linking time series attribute data to a se-
ries of locations that did not change over time.
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 assign-
ing 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 the-
matic 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 func-
tionality through attributes is much more complicated.
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 en-
tries 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 de-
fault. 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.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 cate-
gory (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 and
v.db.dropcolumn. A table column can be renamed with v.db.renamecolumn.
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 rec-
ommended to use SQL (db.execute).
Geometry operations
The module v.in.region saves the current region extents as a vector
area. Split vector lines can be converted 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.drape or 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. Unpro-
jected maps can be geocoded with v.transform. Based on the control
points, v.rectify rectifies a vector map by computing a coordinate
transformation for each vector object. Triangulation and
point-to-polygon conversions can be done with 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.overlay and
v.select, depending on the combination of vector types. Vectors can be
extracted with v.extract and reclassified with v.reclass.
Vector statistics
Statistics can be generated by v.qcount, v.sample, v.normal, v.univar,
and v.vect.stats. Distances between vector objects are calculated with
v.distance.
Vector-Raster-DB conversion
The v.to.db transfers vector information into database tables. With
v.to.points, v.to.rast and v.to.rast3 conversions are performed. Note
that a raster mask ("MASK") will not be respected since it is only ap-
plied when reading an existing GRASS raster map.
Vector queries
Vector maps can be queried with v.what and v.what.vect.
Vector-Raster queries
Raster values can be transferred to vector maps with v.what.rast and
v.rast.stats.
Vector network analysis
GRASS provides support for vector network analysis. The following algo-
rithms are implemented:
• Network preparation and maintenance: v.net
• Shortest path: d.path and v.net.path
• Shortest path between all pairs of nodes v.net.allpairs
• Allocation of sources (create subnetworks, e.g. police station
zones): v.net.alloc
• Iso-distances (from centers): v.net.iso
• Computes bridges and articulation points: v.net.bridge
• Computes degree, centrality, betweeness, closeness and eigen-
vector centrality measures: v.net.centrality
• Computes strongly and weakly connected components: v.net.compo-
nents
• Computes vertex connectivity between two sets of nodes:
v.net.connectivity
• Computes shortest distance via the network between the given
sets of features: v.net.distance
• Computes the maximum flow between two sets of nodes: v.net.flow
• Computes minimum spanning tree:v.net.spanningtree
• Minimum Steiner trees (star-like connections, e.g. broadband
cable connections): v.net.steiner
• Finds shortest path using timetables: v.net.timetable
• Traveling salesman (round trip): v.net.salesman
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.
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
reference system.
The LRS tutorial explains further details.
Interpolation and approximation
Some of the vector modules deal with spatial or volumetric approxima-
tion (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 from text files
with v.in.ascii or from LAS files with v.in.lidar. Both modules recog-
nize the -b flag to not build topology. Outlier detection is done with
v.outlier on both first and last return data. Then, with v.li-
dar.edgedetection, edges are detected from last return data. The build-
ing are generated by v.lidar.growing from detected edges. The result-
ing data are post-processed with v.lidar.correction. Finally, the DTM
and DSM are generated with v.surf.bspline (DTM: uses the ’v.lidar.cor-
rection’ output; DSM: uses last return output from outlier detection).
In addition, v.decimate can be used to decimates a point cloud.
See also
• Introduction to raster data processing
• Introduction to 3D raster data (voxel) processing
• Introduction to image processing
• Introduction into temporal data processing
• Introduction to database management
• Projections and spatial transformations
SOURCE CODE
Available at: Vector data processing in GRASS GIS source code (history)
Accessed: unknown
Main index | Vector index | Topics index | Keywords index | Graphical
index | Full index
© 2003-2022 GRASS Development Team, GRASS GIS 7.8.7 Reference Manual
GRASS 7.8.7 vectorintro(1grass)
Generated by dwww version 1.14 on Fri Jan 24 06:08:27 CET 2025.