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.