This section provides an overview of the data that you generate, store, and manipulate to obtain spatial information. The topics covered are:
In DB2 Spatial Extender, a geographic feature can be represented by a row in a table or view, or by a portion of such a row. For example, consider two of the geographic features mentioned in The purpose of DB2 Spatial Extender, office buildings and residences. In Figure 1, each row of the BRANCHES table represents a branch office of a bank. As a variation, each row of the CUSTOMERS table in Figure 1, taken as a whole, represents a customer of the bank. However, part of each row--specifically, the cells that contain a customer's address--can be regarded as representing the customer's residence.
Figure 1. Table row that represents a geographic feature; table row whose address data represents a geographic feature. The row of data in the BRANCHES table represents a branch office of a bank. The cells for address data in the CUSTOMERS table represent the residence of a customer. The names and addresses in both tables are fictional.
|
The tables in Figure 1 contain data that identifies and describes the bank's branches and customers. Such data is called attribute data.
A subset of the attribute data--the values that denote the branches' and customers' addresses--can be translated into values that yield spatial information. For example, as shown in Figure 1, one branch office's address is 92467 Airzone Blvd., San Jose CA 95141. A customer's address is 9 Concourt Circle, San Jose CA 95141. DB2 Spatial Extender can translate these addresses into values that indicate where the branch and the customer's home are situated with respect to their surroundings. Figure 2 shows the BRANCHES and CUSTOMERS tables with new columns that are designated to contain such values.
Figure 2. Tables with spatial columns added. In each table, the LOCATION column will contain coordinates that correspond to the addresses.
 |
When addresses and similar identifiers are used as the starting point for spatial information, they are called source data. Because the values derived from them yield spatial information, these derived values are called spatial data. The next section describes spatial data and introduces its associated data types.
Much spatial data is made up of coordinates. A coordinate is a number that denotes a position that is relative to a point of reference. For example, latitudes are coordinates that denote positions relative to the equator. Longitudes are coordinates that denote positions relative to the Greenwich meridian. Thus, the position of Yellowstone National Park is defined by its latitude (44.45 degrees north of the equator) and its longitude (110.40 degrees west of the Greenwich meridian).
Latitudes, longitudes, their points of reference, and other associated parameters are referred to collectively as a coordinate system. Coordinate systems based on values other than latitude and longitude also exist. These coordinate systems have their own measures of position, points of reference, and additional distinguishing parameters.
The simplest spatial data item consists of two coordinates that define the position of a single geographic feature. (A data item is the value or values that occupy a cell of a relational table.) A more extensive spatial data item consists of several coordinates that define a linear path such as a road or river might form. A third kind consists of coordinates that define the perimeter of an area; for example, the rim of a land parcel or flood plain. These and other kinds of spatial data items that DB2 Spatial Extender supports are described more fully in Geometries and associated spatial functions.
Each spatial data item is an instance of a spatial data type. The data type for two coordinates that mark a location is ST_Point; the data type for coordinates that define linear paths is ST_LineString; and the data type for coordinates that define perimeters is ST_Polygon. These types, together with the other data types for spatial data, are structured types that belong to a single hierarchy. For an overview of the hierarchy, see About spatial data types.
You can obtain spatial data by:
DB2 Spatial Extender can derive spatial data from attribute data, such as addresses (as mentioned in How data represents geographic features). This process is called geocoding. To see the sequence involved, consider Figure 2 as a "before" picture and Figure 3 as an "after" picture. Figure 2 shows that the BRANCHES table and the CUSTOMERS table both have an empty column designated for spatial data. Suppose that DB2 Spatial Extender geocodes the addresses in these tables to obtain coordinates that correspond to the addresses, and places the coordinates into the columns. Figure 3 illustrates this result.
Figure 3. Tables that include spatial data derived from source data. The LOCATION column in the CUSTOMERS table contains coordinates that a geocoder derived from the address in the ADDRESS, CITY, STATE, and ZIP columns. Similarly, the LOCATION column in the BRANCHES table contains coordinates that the geocoder derived from the address in this table's ADDRESS, CITY, STATE, and ZIP columns. This example is fictional; simulated coordinates, not actual ones, are shown.
 |
DB2 Spatial Extender uses a function, called a geocoder, to translate attribute data into spatial data and to place this spatial data into table columns. For more information about geocoders, see About geocoding.
Spatial data can be generated not only from attribute data, but also from other spatial data. For example, suppose that the bank whose branches are defined in the BRANCHES table wants to know how many customers are located within five miles of each branch. Before the bank can obtain this information from the database, it must supply the database with the definition of the zone that lies within a five-mile radius around each branch. A DB2 Spatial Extender function, ST_Buffer, can create such a definition. Using the coordinates of each branch as input, ST_Buffer can generate the coordinates that demarcate the perimeters of the desired zones. Figure 4 shows the BRANCHES table with information that is supplied by ST_Buffer.
Figure 4. Table that includes new spatial data derived from existing spatial data. The coordinates in the SALES_AREA column were derived by the ST_Buffer function from the coordinates in the LOCATION column. Like the coordinates in the LOCATION column, those in the SALES_AREA column are simulated; they are not actual.
 |
In addition to ST_Buffer, DB2 Spatial Extender provides several other functions that derive new spatial data from existing spatial data. For descriptions of ST_Buffer and these other functions, see Functions that generate new geometries from existing ones.
A third way to obtain spatial data is to import it from files that are in one of the formats that DB2 Spatial Extender supports. For descriptions of these formats, see File formats for spatial data. These files contain data that is usually applied to maps: census tracks, flood plains, earthquake faults, and so on. By using such data in combination with spatial data that you produce, you can augment the geographic information available to you. For example, if a public works department needs to determine what hazards a residential community is vulnerable to, it could use ST_Buffer to define a zone around the community. The public works department could then import data on flood plains and earthquake faults to see which of these problem areas overlap the zone.