Difference between revisions of "Vector Data"
(→Specs) |
(→Vector Data Structures) |
||
Line 3: | Line 3: | ||
[http://en.wikipedia.org/wiki/Caveat_emptor Caveat emptor!] Different termionlogy (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. | [http://en.wikipedia.org/wiki/Caveat_emptor Caveat emptor!] Different termionlogy (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 implementations of vector data. The following is a programmer's perspective a very informal, yet from a user point of view a rather formal discussion on the most widely-used vectordata structures and formats encountered in FOSS geoformatics. | + | The confusion is greatly enhanced by very different implementations of vector data. The following is from a programmer's perspective a very informal, yet from a user point of view a rather formal discussion on the most widely-used vectordata structures and formats encountered in FOSS geoformatics. |
The reader is assumed to be famililiar with the | The reader is assumed to be famililiar with the |
Revision as of 01:22, 30 July 2007
Contents
Vector Data Structures
Caveat emptor! Different termionlogy (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 implementations of vector data. The following is from a programmer's perspective a very informal, yet from a user point of view a rather formal discussion on the most widely-used vectordata structures and formats encountered in FOSS geoformatics.
The reader is assumed to be famililiar with the chapter 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.
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(layer?) <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 dispay 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 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 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)
/*TODO*/
- GRASS GIS Manual: Linear Reference System Tutorial
- R. Blazek: Introducing the Linear Reference System in GRASS (March 2005, Int'l Journal of Geoinformatics, Vol. 1(3), pp. 95-100)
- R. Blazek: Introducing the Linear Reference System in GRASS (Sept 2004, Conference Paper)
- http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/vector/v.lrs/MAIL
- PostGIS Reference, Chapter 6 PostGIS Extensions: 6.2.7. Linear Referencing
Specs
- http://mpa.itc.it/markus/grass63progman/Vector_Library.html#background (PDF version)
- R. Blazek, M. Neteler, R. Micarelli: The new GRASS 5.1 vector architecture (Sept 2002, Conference-Paper)
- R. Blazek: GRASS 6 vector TODO (May 2006)
GRASS
- http://www.intevation.de/rt/webrt?display=History&serial_num=3877
- http://www.gdal.org/ogr/drv_grass.html
- http://www.gdf-hannover.de/lit_html/grass60_v1.2_en/node46.html
- J. Čepický, M. Landa: GRASS GIS Digitization Tools (Feb. 2007, Conference Paper) focuses on v.digit, v.edit and QGIS/GRASS
ESRI Shapefile
A 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 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 ommitted, by specifing 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.
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
- ESRI: Shapefile Technical Description (July 1998, Whitepaper) (mirrored copy)
- ESRI: Linear Referencing and Dynamic Segmentation in ArcGIS 8.1 (May 2001, Whitepaper) (has a section called "Routes and Measures", that explains measures in shapefiles)
OpenGIS Simple Features
is a widely implemented nontopological standard. The internal data representation of [OGR] is closely modeled after it, PostGIS is a PostgreSQL implemenation and the Spatial Extentions of MySQL implement it too, etc..
The following vector objects are defined:
- Point
- LineString
- Polygon
- Multipoint
- Multipolygon
- GeomCollection
Specs
- OpenGIS: Simple Features Specifications For SQL
- http://www.opengeospatial.org/standards
- http://en.wikipedia.org/wiki/Simple_Features
GRASS
- v.external
- http://grass.itc.it/gdp/html_grass63/v.in.ogr.html
- http://grass.itc.it/gdp/html_grass63/v.out.ogr.html
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
- http://grass.itc.it/grass63/manuals/html63_user/v.out.svg.html and http://svg.cc/grass/
- GRASS vector export to Inkscape
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)
- 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
futher some garmin devices (forerunner?) feature..
- 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
- 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;
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
http://www.ncc.up.pt/gpsman/gpsmanhtml/manual/html/GPSMandoc_15.html