Vector data processing 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 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.
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).
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,
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 objects 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 boundary;
area: the topological composition of centroid and boundary;
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 nodes in between).
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.
Adjacent polygons can be found by v.to.db
(see 'sides' option).
GRASS 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 the vector map.
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
can be done with v.db.addcol. To drop a table from a map, use
v.db.droptable. Values in a table can be updated
- Categories: The category number is the vector ID. It is
used to link attribute(s) to each vector object. A vector object can
have zero, one, two, or more categories. Category numbers are stored
both within the geometry file and within the attribute table(s) for each
vector object (usually the "cat" column).
Using v.category, category numbers can be
printed or maintained. In order to link one vector object to several
attribute tables, several category numbers per vector object are needed.
- Layers: 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 numbers
in a geometry file corresponds to a row in the attribute table
(the linking column is usually the "cat" key column). Using
v.db.connect layers can be listed
GRASS layers do not contain any geographic objects, but they
consist of links to 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 subsequent layers.
- SQL support: The DBF driver provides only very limited SQL
support (as DBF is not an SQL DB) while the other DBMS backends (such
as 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.
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
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
Buffer and circles can be generated with v.buffer
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
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 v.delaunay, v.hull,
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.
Statistics can be generated by v.qcount,
Distances between vector objects are calculated with v.distance.
The v.to.db transfers vector information
into database tables.
v.to.rast and v.to.rast3
conversions are performed.
Vector maps can be queried with v.what and
Raster values can be transferred to vector maps with
Vector network analysis
GRASS provides support for vector network analysis. The following algorithms
Vector directions are defined by the digitizing direction (a-->--b).
Both directions are supported, network modules provide parameters
to assign attribute columns to the forward and backward direction.
Vector networks: Linear reference 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,
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
approximation (also called interpolation):
Lidar data processing
Lidar point clouds (first and last ping) are imported with v.in.ascii (-b flag to not build the
topology). Outlier detection is done with
v.outlier on both first and last ping data.
Then, with v.lidar.edgedetection,
edges are detected from last ping 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 ping output
from outlier detection).
Main index - vector index - full index