## Documentation Center |

Geospatial data comes in many forms and formats, and its structure
is more complicated than tabular or even nongeographic geometric data.
It is, in fact, a subset of spatial data, which is simply data that
indicates where things are within a given *coordinate system*.
Mileposts on a highway, an engineering drawing of an automobile part,
and a rendering of a building elevation all have coordinate systems,
and can be represented as spatial data when properly quantified (digitized).
Such coordinate systems, however, are local and not explicitly tied
or oriented to the Earth's surface; thus, most digital representations
of mileposts, machine parts, and buildings do not qualify as geospatial
data (also called *geodata*).

What sets geospatial data apart from other spatial data is that
it is absolutely or relatively positioned on a planet, or *georeferenced*.
That is, it has a *terrestrial coordinate system* that
can be shared by other geospatial data. There are many ways to define
a terrestrial coordinate system and also to transform it to any number
of local coordinate systems, for example, to create a map projection.
However, most are based on a framework that represents a planet as
a sphere or spheroid that spins on a north-south axis, and which is
girded by an *equator* (an imaginary plane midway
between the poles and perpendicular to the rotational axis).

Geodata is coded for computer storage and applications in two
principal ways: *vector* and *raster* representations.
It has been said that "raster is faster but vector is corrector."
There is truth to this, but the situation is more complex. The following
discussions explore these two representations: how they differ, what
data structures support them, why you would choose one over the other,
and how they can work together in the toolbox. The conclude by summarizing
the functions available for importing and exporting geospatial data
formats.

Was this topic helpful?