Provided by: grass-doc_6.4.3-3_all bug


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

       The  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 -h mapname).  Metadata such as
       map title, scale, organization etc. can be updated with

   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 (,

   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 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  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

                      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
       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 (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  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 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
                     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, 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  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 saves the current region boundary into a vector area.  Split vector
       lines can be changes to polylines by 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,,  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  transfers  vector  information  into  database  tables.   With, 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

                      Network preparation and maintenance:

                      Shortest path: d.path and

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

                      Iso-distances (from centers):

                      Minimum  Steiner  trees  (star-like  connections,  e.g.   broadband   cable

                      Traveling salesman (round trip):
       --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,,, and v.vol.rst.

   Lidar data processing
       Lidar  point  clouds  (first  and  last  return)  are  imported  from  text files  with <a
       href=""> (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  (DTM:
       uses   the  'v.lidar.correction'  output;  DSM:  uses  last  return  output  from  outlier

   See also
                     Introduction to GRASS database management

                     Introduction to GRASS raster map processing

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

       © 2008-2012 GRASS Development Team