Vector data processing in GRASS GIS

Vector import

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.

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.overlay,v.select).

Vector model and topology

GRASS is a topological GIS. This means that adjacent geographic components in a single vector file 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 available:

point: a point
line: a sequence of vertices connected by line(s) with two endpoints called nodes
boundary: the border line of an area
centroid: the label point of an area
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 (not yet implemented)

The v.type module can be used to convert between vector types if possible. The v.build module is used to identify topological errors. It allows to optionally 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).

Attribute management

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.

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. The category number is stored within the geometry file for each vector object. Using v.category the category numbers can be printed or maintained.
Layers: It is possible to link the geographic objects in one vector file to one or more tables. Each link to a distinct attribute table is called a layer. GRASS layers do not contain any geographic objects, but consist of links to attribute tables in which vector objects can have zero or more categories. If a vector object has zero categories in a layer, then it does not appear in that layer. In this fasion 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 in a single file (e.g. forests and lakes). These virtual layers also are 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. Using v.db.connect layers can be listed or maintained.
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.

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.

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.