Ubuntu Manpage: vectorintro - Vector data processing

NAME

       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_]*).

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 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 between).

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 the user to extract 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 wxGUI vector digitizer. 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
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
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 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 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
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 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
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).

Geometry operations
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.

Vector statistics
Statistics can be generated by v.qcount, v.normal, and v.univar. 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.rast3 conversions are performed.

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 algorithms are
implemented:

Network preparation and maintenance: v.net

Shortest path: d.path and v.net.path

Allocation of sources (create subnetworks, e.g. police station zones):
v.net.alloc

Iso-distances (from centers): v.net.iso

Minimum Steiner trees (star-like connections, e.g. broadband cable
connections): v.net.steiner

Traveling salesman (round trip): v.net.salesman
--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 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 from text files with <a
href="v.in.ascii.html">v.in.ascii (use the -b flag to not build 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).

See also
Introduction to GRASS database management

Introduction to GRASS raster map processing

Introduction to GRASS 3D raster map (voxel) processing
full index