Provided by: grass-doc_8.3.2-1ubuntu2_all bug

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.

   Attribute management
       The  default  database driver used by GRASS GIS 8 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 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.

       GRASS GIS vector map exchange between different locations (same projection) can be done in a lossless way
       using the v.pack and v.unpack modules.

       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.overlay, 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 representation 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  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 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 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 located 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 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 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’ 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 with
       which the centroid is associated. 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" 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
               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 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.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 recommended 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.   Unprojected  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 applied 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 algorithms 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  eigenvector   centrality   measures:
               v.net.centrality

           •   Computes strongly and weakly connected components: v.net.components

           •   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 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 v.in.ascii or from LAS files
       with v.in.lidar. Both modules recognize 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).
       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: Wednesday Mar 06 21:24:05 2024

       Main index | Vector index | Topics index | Keywords index | Graphical index | Full index

       © 2003-2024 GRASS Development Team, GRASS GIS 8.3.2 Reference Manual

GRASS 8.3.2                                                                                  vectorintro(1grass)