Vector Data: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(Linear Reference System (LRS) moved out to own page)
 
(43 intermediate revisions by 6 users not shown)
Line 1: Line 1:
= Vector Data Structures =  
= Vector Data Structures =  


reading recommendation: chapter [http://grass.itc.it/grass63/manuals/html63_user/vectorintro.html Vector data processing in GRASS GIS] in GRASS GIS Reference Manual
[http://en.wikipedia.org/wiki/Caveat_emptor Caveat emptor!] Different terminology (eg. vertex, node, point or edge, line, line segment, link) due to different vocabulary in the underlying theories (e.g. linear algebra, graph theory, network theory) of vector data can already lead to great confusion.
 
The confusion is greatly enhanced by very different concepts and implementations of vector data.
 
Hence a discussion of the currently most widely vector data structures and formats in the geoiformatics field is surely not bad, IMO. Naturally the focus is GRASS and FOSS4G centric, maybe almost too formal form a user's point of view, and yet certainly way too informal from a programmers point of view.
 
The reader is assumed to be familiar with the section {{cmd|vectorintro}} (Vector data processing in GRASS GIS) in the GRASS GIS Reference Manual, the Wiki topics [[Vector FAQ GRASS6]] and [[Help with 3D#Vector_3D_point_data]].
Also reading [http://mapserver.gis.umn.edu/docs/reference/vector_data Vector Data Access] from the Mapserver Documentation does not hurt.


==  GRASS 6 Vector Architecture ==
==  GRASS 6 Vector Architecture ==
[[Image:Grass_vector_line.png]]
[[Image:Grass_vector_area.png]]


The GRASS vector data model includes the description of topology, where besides the coordinates describing the location of the primitives (points, lines, boundaries and centroids), their spatial relations are also stored. In general, topological GIS require a data structure where the common boundary between two adjacent areas is stored as a single line, simplifying the map maintenance.
The GRASS vector data model includes the description of topology, where besides the coordinates describing the location of the primitives (points, lines, boundaries and centroids), their spatial relations are also stored. In general, topological GIS require a data structure where the common boundary between two adjacent areas is stored as a single line, simplifying the map maintenance.


The following vector objects are defined:
The following vector objects are defined:
Line 22: Line 33:
* volume: a 3D corpus, the topological composition of faces and kernel (not yet implemented)
* volume: a 3D corpus, the topological composition of faces and kernel (not yet implemented)


'''Note:''' all lines and boundaries can be polylines (with nodes(vertices) in between)
'''Note:''' all lines and boundaries can be polylines (with nodes/vertices in between). {{cmd|v.build.polylines}} creates these.


=== Data Structure ===  
=== Data Structure ===  


a vector map(layer?) '''<some_vector>''' is stored in the directory '''$MAPSET/vector/<some_vector>'''.
a vector map '''<some_vector>''' is stored in the directory '''$MAPSET/vector/<some_vector>'''.
This directory normally contains the files listed below.
This directory normally contains the files listed below.


* /[http://mpa.itc.it/markus/grass63progman/Vector_Library.html#head_file_format head]: ASCII file with header information; this is more or less the stuff that '''v.info''' displays.
* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#head_file_format head]: ASCII file with header information; this is more or less the stuff that '''v.info''' displays.
 
* /[http://mpa.itc.it/markus/grass63progman/Vector_Library.html#vlib_attributes dbln]: ASCII file that link(s) to attribute table(s)


* /hist: ASCII file with vector map change history. '''v.info -h''' can be used to dispay this file.
* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#vlib_attributes dbln]: ASCII file that link(s) to attribute table(s)


* /[http://mpa.itc.it/markus/grass63progman/Vector_Library.html#coor_file_format_specification coor]: binary file for storing the coordinates
* /hist: ASCII file with vector map change history. '''v.info -h''' can be used to display this file.


* /[http://mpa.itc.it/markus/grass63progman/Vector_Library.html#topo_file_format topo]: binary file for topology
* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#coor_file_format_specification coor]: binary file for storing the coordinates


* /[http://mpa.itc.it/markus/grass63progman/Vector_Library.html#vlib_cidx cidx]: binary category index
* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#topo_file_format topo]: binary file for topology


* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#vlib_cidx cidx]: binary category index


'''Note:''' The creation of certain files can be disabled. The '''-t''' flag suported by v.in.ogr and v.in.ascii disables the creation of an attribute table. The '''-b''' flag supported by r.to.vect and v.in.ascii disables the creation of a topology file. This is [http://www.intevation.de/rt/webrt?display=History&serial_num=3877 needed] and useful e.g. for very large datasets (> 3 million points). The user is expected to understand what s/he is doing.


'''Note:''' The creation of certain files can be disabled. The '''-t''' flag supported by v.in.ogr and v.in.ascii disables the creation of an attribute table. The '''-b''' flag supported by {{cmd|r.to.vect}} and {{cmd|v.in.ascii}} disables the creation of a topology file. This is [http://www.intevation.de/rt/webrt?display=History&serial_num=3877 needed] and useful e.g. for very large datasets (> 3 million points). The user is expected to understand what s/he is doing.


=== Linear Reference System (LRS) ===
=== Linear Reference System (LRS) ===


/*TODO*/
* see [[Linear Reference System]]
 
* R. Blazek: [http://www.j-geoinfo.net/Content/fulmar05/IJG_095-100.pdf Introducing the Linear Reference System in GRASS] (March 2005, Int'l Journal of Geoinformatics, Vol. 1(3), pp. 95-100)
* R. Blazek: [http://gisws.media.osaka-cu.ac.jp/grass04/viewpaper.php?id=50 Introducing the Linear Reference System in GRASS] (Sept 2004, Conference Paper)
* PostGIS Reference, Chapter 6 [http://postgis.refractions.net/docs/ch06.html#id2646260 PostGIS Extensions: 6.2.7. Linear Referencing]
<!--
http://en.wikipedia.org/wiki/Linear_Reference_System
http://grass.itc.it/grass63/manuals/html63_user/lrs.html
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/vector/v.lrs/lrs.html
http://pgrouting.postlbs.org/
 
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.lrs/lib/
http://postgis.refractions.net/pipermail/postgis-users/2006-July/012537.html
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/vector/v.lrs/MAIL
 
Linear referencing is a natural and convenient means to associate attributes or events to locations or portions of a linear feature. It has been widely used in transportation applications (such as for highways, railroads, and transit routes) and utilities applications (such as for gas and oil pipelines). The major advantage of linear referencing is its capability of locating attributes and events along a linear feature with only one parameter (usually known as measure) instead of two (such as latitude/longitude or x/y in Cartesian space). Sections of a linear feature can be referenced and created dynamically by indicating the start and end locations along the feature without explicitly storing them. http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96630/sdo_lrs_concepts.htm -->


=== Specs ===
=== Specs ===
* http://mpa.itc.it/markus/grass63progman/Vector_Library.html#background
* http://grass.osgeo.org/programming6/Vector_Library.html
* R. Blazek, M. Neteler, R. Micarelli: [http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf The new GRASS 5.1 vector architecture] (Conference-Paper, Sept 2002)
* http://grass.osgeo.org/programming7/Vector_Library.html
* R. Blazek, M. Neteler, R. Micarelli: [http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf The new GRASS 5.1 vector architecture] (Sept 2002, Conference-Paper)


=== GRASS ===
=== GRASS ===
* http://www.intevation.de/rt/webrt?display=History&serial_num=3877
 
* http://www.gdal.org/ogr/drv_grass.html
* [[Vector FAQ GRASS6]] and [[Help_with_3D#Vector_3D_point_data]]
* http://www.gdf-hannover.de/lit_html/grass60_v1.2_en/node46.html
* http://www.gdf-hannover.de/lit_html/grass60_v1.2_en/node46.html
* J. Čepický, M. Landa: [http://gislab.dirap.unipa.it/grass_meeting/articoli/grass-digit.pdf GRASS GIS Digitization Tools] (Conference Paper, Feb. 2007) focuses on v.digit, v.edit and QGIS/GRASS
* J. Čepický, M. Landa: [http://gislab.dirap.unipa.it/grass_meeting/articoli/grass-digit.pdf GRASS GIS Digitization Tools] (Feb. 2007, Conference Paper) focuses on v.digit, v.edit and QGIS/GRASS


==  ESRI Shapefile ==
==  ESRI Shapefile ==


A [http://en.wikipedia.org/wiki/Shapefile shapefile] stores nontopological geometry and attribute information for the spatial features in a data set. The geometry for a feature is stored as a shape comprising a set of
A [http://en.wikipedia.org/wiki/Shapefile shapefile] stores non-topological geometry and attribute information for the spatial features in a data set. The geometry for a feature is stored as a shape comprising a set of
vector coordinates.
vector coordinates.


Line 95: Line 89:
* MultiPointM: MultiPoint plus support for a Measure
* MultiPointM: MultiPoint plus support for a Measure


* PointZ: 3D PointM<!-- or is it just 2.5D ?? ..mmh should consult the literature -->
* PointZ: 3D capable version of PointM
* PolyLineZ: 3D PolyLineM
* PolyLineZ: 3D capable version of PolyLineM
* PolygonZ: 3D PolygonM
* PolygonZ: 3D capable version of PolygonM
* MultiPointZ: 3D MultiPointM
* MultiPointZ: 3D capable version of MultiPointM
* MultiPatch: A MultiPatch consists of a number of surface patches. Each surface patch describes a surface.
 
* MultiPatch: consists of a number of surface patches, each patch describes a surface. [http://en.wikipedia.org/wiki/Triangulated_irregular_network TIN]-like.
 
'''Note:''' the "measure" or the z-coord may always be omitted, by specifying the null element. e.g. a PolyLineZ(x,y,0,0) is the same as a PolyLineM(x,y,0) which is the same as PolyLine(x,y)
 
'''Note:''' Unlike [http://shapelib.maptools.org/shp_api.html Shapelib] OGR does [http://www.gdal.org/ogr/drv_shapefile.html not support] MultiPatch, PointM, PolyLineM, PolygonM, MultiPointM are [http://www.gdal.org/ogr/drv_shapefile.html not supported] by OGR. Hence GRASS also does not support them. Postgres has an almost complete support (with some limitations, and lacking documentation)
 


=== Data Structure ===
=== Data Structure ===


a shapefile is actually a dataset of files:
a shapefile '''<some_vector>''' is actually a set of files:
* '''.shp''' vector features
* '''<some_vector>.shp''' vector features
* '''.shx''' feature index
* '''<some_vector>.shx''' feature index data pointing to the vector features
* '''.dbf''' attributes in [http://www.clicketyclick.dk/databases/xbase/format/index.html dBase DB] format
* '''<some_vector>.dbf''' attributes in [http://www.clicketyclick.dk/databases/xbase/format/index.html dBase DB] format
* '''.prj''' ASCII file with projection info in [http://en.wikipedia.org/wiki/Well-known_text WKT] format
* '''<some_vector>.prj''' ASCII file with projection info in [http://en.wikipedia.org/wiki/Well-known_text WKT] format
 
* '''<some_vector>.sbn''' optional spatial index file


* .sbn optional spatial index file
This set of files is often packed into a zip-compressed archive '''<some_vector>.zip''' or placed into a unique directory '''../<some_vector>/'''


=== Specs ===
=== Specs ===
* ESRI: [http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf Shapefile Technical Description] (Whitepaper, July 1998) ([http://shapelib.maptools.org/dl/shapefile.pdf mirrored copy])
* ESRI: [http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf Shapefile Technical Description] (July 1998, Whitepaper) ([http://shapelib.maptools.org/dl/shapefile.pdf mirrored copy])
* ESRI: [http://www.esri.com/library/whitepapers/pdfs/lrds_arcgis.pdf Linear Referencing and Dynamic Segmentation in ArcGIS 8.1] (Whitepaper, May 2001) (has a section called "Routes and Measures", that explains measures in shapefiles)
* ESRI: [http://www.esri.com/library/whitepapers/pdfs/lrds_arcgis.pdf Linear Referencing and Dynamic Segmentation in ArcGIS 8.1] (May 2001, Whitepaper) (has a section called "Routes and Measures", that explains measures in shapefiles)


* http://www.gdal.org/ogr/drv_shapefile.html
* OGR documentation: [http://www.gdal.org/ogr/drv_shapefile.html Shapefile Driver]
* http://shapelib.maptools.org/
* http://shapelib.maptools.org/
* http://mapserver.gis.umn.edu/docs/reference/vector_data/shapefiles


== OpenGIS Simple Features ==
== OpenGIS Simple Features ==


is a widely implemented nontopological standard. The internal data representation of [OGR] is closely modeled after it, [http://postgis.refractions.net/ PostGIS] is a PostgreSQL implemenation and the [http://dev.mysql.com/doc/refman/5.1/en/spatial-extensions.html Spatial Extentions] of MySQL implement it too, etc..
[http://en.wikipedia.org/wiki/Simple_Features Simple Features] is a widely implemented non-topological standard. The internal data representation of OGR is closely modeled after it, [http://postgis.refractions.net/ PostGIS] is a PostgreSQL implementation and the [http://dev.mysql.com/doc/refman/5.1/en/spatial-extensions.html Spatial Extensions] of MySQL implement it too, etc.


The following vector objects are defined:
The following vector objects are defined:
Line 133: Line 136:
=== Specs ===
=== Specs ===
* OpenGIS: [http://www.opengis.org/docs/99-049.pdf Simple Features Specifications For SQL]
* OpenGIS: [http://www.opengis.org/docs/99-049.pdf Simple Features Specifications For SQL]
* Adam Gawne-Cain: [http://home.gdal.org/projects/opengis/twohalfdsf.html 2.5 D Simple Features Proposal (OGC 99-402r2)]
* http://www.opengeospatial.org/standards
* http://www.opengeospatial.org/standards
* http://en.wikipedia.org/wiki/Simple_Features


=== GRASS ===
=== GRASS ===
* [http://grass.itc.it/gdp/html_grass63/v.external.html v.external]
* {{cmd|v.external}}
* http://grass.itc.it/gdp/html_grass63/v.in.ogr.html
* {{cmd|v.in.ogr}}
* http://grass.itc.it/gdp/html_grass63/v.out.ogr.html
* {{cmd|v.out.ogr}}


== SVG ==
== SVG ==


is a non-topological W3C standard. The following vector objects are defined:
is a non-topological, non-spatial W3C vector format standard. The following vector objects are defined:


* [http://www.w3.org/TR/SVG/paths.html path]: represents the outline of a shape
* [http://www.w3.org/TR/SVG/paths.html path]: represents the outline of a shape
Line 157: Line 160:


=== GRASS ===
=== GRASS ===
* http://grass.itc.it/grass63/manuals/html63_user/v.out.svg.html and http://svg.cc/grass/
* {{cmd|v.out.svg}}
* [[GRASS vector export to Inkscape]]
* [[GRASS vector export to Inkscape]]


== GPS vector data ==
== GPS receiver vector data ==
 
Waypoints, routes, tracks and laps are examples of data used in GPS receivers.


* '''waypoint''' (WP): point given by its geographic coordinates (usually, user-defined)
* '''waypoint''' (WP): point given by its geographic coordinates (usually, user-defined)
* '''route''' (RT) a sequence of waypoints (usually, user-defined)
* '''route''' (RT) a sequence of waypoints (usually, user-defined)
* '''track point''' (TP) a point given by its geographic coordinates with a time-stamp
* '''track point''' (TP) a point given by its geographic coordinates with a time-stamp
* '''track''' (TR) (Lowrance calls it: '''Trail''') is a sequence of '''track points''' recorded by the GPS receiver during a certain time-interval
* '''track''' (TR) (Lowrance calls it: '''trail''') is a sequence of '''track points''' recorded by the GPS receiver during a certain time-interval


futher some garmin devices (forerunner?) feature..
=== Specs ===
* [http://www.gpsbabel.org/ GpsBabel] Documentation: [http://www.gpsbabel.org/htmldoc-1.3.4/Route_And_Track_Modes.html Route and Track Modes]
: GpsBabel performs GPS format and receiver interchange
* http://www.ncc.up.pt/gpsman/gpsmanhtml/manual/html/GPSMandoc_15.html
 
 
=== GRASS ===


* '''lap''' has a time-stamp for its start, a duration, the total distance, the calories spent, the start and stop positions, and an associated track
* {{cmd|v.in.garmin}}
* '''run''' a sequence of laps is called a run, and runs are represented in GPSMan by groups that are automatically created when getting laps from the receiver; support for laps in GPSMan exists only for Garmin receivers and must be explicitly selected from the options (receiver parameters) window;
* {{cmd|v.in.gpsbabel}}
* {{cmd|v.out.gpsbabel}} (in development)


Route stages are the parts of a route between each two consecutive waypoints. Route stages are called edges in Graph Theory, legs in aviation, and links by Garmin
: ''v.in|out.gpsbabel will be renamed/replaced with v.in|out.gps in GRASS 7.''


http://www.ncc.up.pt/gpsman/gpsmanhtml/manual/html/GPSMandoc_15.html
[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Vector]]

Latest revision as of 19:53, 2 September 2012

Vector Data Structures

Caveat emptor! Different terminology (eg. vertex, node, point or edge, line, line segment, link) due to different vocabulary in the underlying theories (e.g. linear algebra, graph theory, network theory) of vector data can already lead to great confusion.

The confusion is greatly enhanced by very different concepts and implementations of vector data.

Hence a discussion of the currently most widely vector data structures and formats in the geoiformatics field is surely not bad, IMO. Naturally the focus is GRASS and FOSS4G centric, maybe almost too formal form a user's point of view, and yet certainly way too informal from a programmers point of view.

The reader is assumed to be familiar with the section vectorintro (Vector data processing in GRASS GIS) in the GRASS GIS Reference Manual, the Wiki topics Vector FAQ GRASS6 and Help with 3D#Vector_3D_point_data. Also reading Vector Data Access from the Mapserver Documentation does not hurt.

GRASS 6 Vector Architecture

The GRASS vector data model includes the description of topology, where besides the coordinates describing the location of the primitives (points, lines, boundaries and centroids), their spatial relations are also stored. In general, topological GIS require a data structure where the common boundary between two adjacent areas is stored as a single line, simplifying the map maintenance.


The following vector objects are defined:

  • point
  • line: directed sequence of connected vertices with 2 endpoints called nodes
  • boundary: the border line to describe an area
  • centroid: a point within a closed boundary (missing centroids can be created with v.centroids)
  • area: the topological composition of centroid and boundary
  • face: a 3D area;

Further following vector objects are defined, but not yet fully implemented/used:

  • kernel: a 3D centroid in a volume (exists, but currently mostly unused)
  • volume: a 3D corpus, the topological composition of faces and kernel (not yet implemented)

Note: all lines and boundaries can be polylines (with nodes/vertices in between). v.build.polylines creates these.

Data Structure

a vector map <some_vector> is stored in the directory $MAPSET/vector/<some_vector>. This directory normally contains the files listed below.

  • /head: ASCII file with header information; this is more or less the stuff that v.info displays.
  • /dbln: ASCII file that link(s) to attribute table(s)
  • /hist: ASCII file with vector map change history. v.info -h can be used to display this file.
  • /coor: binary file for storing the coordinates
  • /topo: binary file for topology
  • /cidx: binary category index


Note: The creation of certain files can be disabled. The -t flag supported by v.in.ogr and v.in.ascii disables the creation of an attribute table. The -b flag supported by r.to.vect and v.in.ascii disables the creation of a topology file. This is needed and useful e.g. for very large datasets (> 3 million points). The user is expected to understand what s/he is doing.

Linear Reference System (LRS)

Specs

GRASS

ESRI Shapefile

A shapefile stores non-topological geometry and attribute information for the spatial features in a data set. The geometry for a feature is stored as a shape comprising a set of vector coordinates.


The following vector objects are defined:

  • Point
  • MultiPoint: a set of points
  • PolyLine: A PolyLine is an ordered set of vertices that consists of one or more parts. A part is a connected sequence of 2 or more points. Parts may or may not be connected to one another. Parts may or may not intersect one another.
  • Polygon: A polygon consists of 1 or more rings. A ring is a connected sequence of 4 or more points that form a closed, non-self-intersecting loop.
  • PointM: Point plus support for a Measure (cf. Measure in shape file)
  • PolyLineM: Point plus support for a Measure
  • PolygonM: Point plus support for a Measure
  • MultiPointM: MultiPoint plus support for a Measure
  • PointZ: 3D capable version of PointM
  • PolyLineZ: 3D capable version of PolyLineM
  • PolygonZ: 3D capable version of PolygonM
  • MultiPointZ: 3D capable version of MultiPointM
  • MultiPatch: consists of a number of surface patches, each patch describes a surface. TIN-like.

Note: the "measure" or the z-coord may always be omitted, by specifying the null element. e.g. a PolyLineZ(x,y,0,0) is the same as a PolyLineM(x,y,0) which is the same as PolyLine(x,y)

Note: Unlike Shapelib OGR does not support MultiPatch, PointM, PolyLineM, PolygonM, MultiPointM are not supported by OGR. Hence GRASS also does not support them. Postgres has an almost complete support (with some limitations, and lacking documentation)


Data Structure

a shapefile <some_vector> is actually a set of files:

  • <some_vector>.shp vector features
  • <some_vector>.shx feature index data pointing to the vector features
  • <some_vector>.dbf attributes in dBase DB format
  • <some_vector>.prj ASCII file with projection info in WKT format
  • <some_vector>.sbn optional spatial index file

This set of files is often packed into a zip-compressed archive <some_vector>.zip or placed into a unique directory ../<some_vector>/

Specs

OpenGIS Simple Features

Simple Features is a widely implemented non-topological standard. The internal data representation of OGR is closely modeled after it, PostGIS is a PostgreSQL implementation and the Spatial Extensions of MySQL implement it too, etc.

The following vector objects are defined:

  • Point
  • LineString
  • Polygon
  • Multipoint
  • Multipolygon
  • GeomCollection

Specs

GRASS

SVG

is a non-topological, non-spatial W3C vector format standard. The following vector objects are defined:

  • path: represents the outline of a shape
  • line: a (directed?) line segment that starts at one point and ends at another.
  • polyline: a set of connected straight line segments. typically, it defines open shapes.
  • polygon: a closed shape consisting of a set of connected straight line segments.
  • rect: defines a rectangle shape
  • circle
  • ellipse

Specs

Scalable Vector Graphics (SVG) 1.1 Specification

GRASS

GPS receiver vector data

  • waypoint (WP): point given by its geographic coordinates (usually, user-defined)
  • route (RT) a sequence of waypoints (usually, user-defined)
  • track point (TP) a point given by its geographic coordinates with a time-stamp
  • track (TR) (Lowrance calls it: trail) is a sequence of track points recorded by the GPS receiver during a certain time-interval

Specs

GpsBabel performs GPS format and receiver interchange


GRASS

v.in|out.gpsbabel will be renamed/replaced with v.in|out.gps in GRASS 7.