Programmatically deriving street geometry from address data

Details Programmatically deriving street geometry from address data Programmatically deriving street geometry from address data

2002-02-15

2003-12-02

McElheny, Jr., Donald E. (Department: 2857)

Data processing: measuring, calibrating, or testing

Measurement system in a specific environment

Earth science

Reexamination Certificate

active

06658356

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to spatially-enabled computer databases, and deals more particularly with techniques for programmatically deriving street geometry from address data supplied in textual format.
2. Description of the Related Art
Geographic information systems are known in the art, and store geographic or cartographic (i.e. map-oriented) data. Systems are also known in the art for using relational databases to process (e.g. store and access) this type of geographic data. When a relational database is adapted for use with geographic information system (“GIS”) data, the database is often referred to as “spatially-enabled”.
Geographic data pertains to physical locations, and when using 2 dimensions, is typically expressed in terms of latitude and longitude. The latitude and longitude values for a particular location are given relative to fixed points of reference, using a coordinate system in which a latitude value represents an offset from the equator and a longitude value represents an offset from the prime meridian.
Geographic data may describe the physical location or area of a place or thing, or even the location of a person. When geographic data is stored in a spatially-enabled database, it is stored using a geometric model in which locations/areas are expressed in terms of geometric shapes or objects. The geometric data stored according to this model may also be referred to as “spatial data”. In addition to locations or areas of geographic objects, spatial data may also represent relationships among objects, as well as measurements or distances pertaining to objects. As an example of relationships among objects, spatial data may be used to determine whether a geometric shape corresponding to the location of a particular bridge intersects a geometric shape corresponding to the location of a river (thus determining whether the bridge crosses the river). As an example of using spatial data for measurements or distances, the length of a road passing through a particular county could be determined using the geometric object representing the road and a geometric object which specifies the boundaries of the county.
Spatial data values are expressed in terms of “geometry” or “geometric” data types. Thus, the location of a landmark might be expressed as a point having (x,y) coordinates, and the perimeter of a lake might be defined using a polygon. Typical spatially-enabled database systems support a set of basic geometry data types and a set of more complex geometry data types, where the basic types comprise points, line strings, and polygons, and the complex types comprise collections of points, collections of line strings, and collections of polygons.
A common geometric model used by spatially-enabled database systems is shown in FIG.
1
. As shown therein, the model is structured as a hierarchy or tree
100
having geometry
105
as its root, and having a number of subclasses. Point
110
, linestring
120
, and polygon
130
represent the basic geometry data types. In this model
100
, linestring
120
is a subclass of curve
115
, and polygon
130
is a subclass of surface
125
. Geometry collection class
135
is the root of a subtree representing the more complex geometric data types, and each subclass thereof is a homogeneous collection. Multipolygon
145
, multistring
155
, and multipoint
160
represent the collections of polygons, line strings, and points, respectively. Multipolygon
145
is a subclass of multisurface
140
in this model, and multistring
155
is a subclass of multicurve
150
. Only the classes which are leaves of this tree
100
are instantiable in typical spatially-enabled database systems; the other nodes correspond to abstract classes. (Each of these entities is an actual data type.)
Referring now to the basic data types in particular, geometric data according to the model
100
of
FIG. 1
may be expressed in terms of a single point having (x,y) coordinates, or may be described as a line string or a polygon. A line string may be considered as one or more line segments which are joined together, and is defined using an ordered collection of (x,y) coordinates (i.e. points) that correspond to the endpoints of the connected segments. A polygon is defined using an ordered collection of points at which a plurality of line segments end, where those line segments join to form a boundary of an area.
Many different examples may be imagined where points, line strings, and polygons can be used for describing locations or areas. A point might represent the location of a landmark such as a house or a building, or the intersection of two streets. A line string might be used to describe a street, or the path of a river or power line, or perhaps a set of driving directions from one location to another. A polygon might be used to describe the shape of a state or city, a voting district, a lake, or any parcel of land or body of water.
Once spatial information has been stored in a database, the database can be queried to obtain many different types of information, such as the distance between two cities, whether a national park is wholly within a particular state, and so forth.
Early geographic information systems relied on proprietary data formats. A widely popular example is the “.shp” shape format. These shape files contain binary data that may represent points, line strings, or polygons relating to geographic locations or areas. Another commonly-used proprietary data format is known as “.EDG”. Files using EDG format contain binary data that provides a mapping between an address and its 2-dimensional geographic location. Efforts have been made in recent years to define open, standardized data formats for GIS data, in order to facilitate exchange of data between systems. This work is characterized by two data formats known as “well known text” and “well known binary”, or simply “WKT” and “WKB”. The Open GIS Consortium, Inc. (“OGC”) is an industry consortium which promulgates standardized specifications including these data formats. The data formats are termed “well known” because they are standardized and therefore non-proprietary. Typical spatially-enabled database systems support one or more of these four data formats.
As one example of a spatially-enabled database, a feature known as “Spatial Extender” can be added to IBM's DB2® relational database product to provide GIS support. Spatial Extender provides support for the geometric data types shown in
FIG. 1
, and provides a number of built-in functions for operating on those data types. When using Spatial Extender, spatial data can be stored in columns of spatially-enabled database tables by importing the data or deriving it. The import process uses one of the WKT, WKB, or “.shp” shape formats described above as source data, and processes that data using built-in functions to convert it to geometric data. For example, WKT format data may be imported using “geometryFromText” functions; similar functions are provided for WKB format data (“geometryFromWKB”) and “.shp” shape data (“geometryFromShape”). Spatial data may be derived either by operating on existing geometric data (for example, by defining a new polygon as a function of an existing polygon) or by using a process known as “geocoding”. A geocoder is provided with Spatial Extender that takes as input an address in the United States, and derives a geometric point representation. Other geocoders can be substituted to provide other types of conversions.
Refer to “IBM® DB2® Spatial Extender User's Guide and Reference”, Version 7.2, published by IBM in July 2001 as IBM publication SC27-0701-01, for more information on Spatial Extender. This User's Guide is hereby incorporated herein as if set forth fully, and is hereinafter referred to as the “Spatial Extender User's Guide”. (“IBM” and “DB2” are registered trademarks of IBM.)
Another example of a spatially-enabled database is the IBM Informix® Spatial DataBlade® product. This database is described in “SDE Version 3.0.2 for Infor

Affiliated with

Also associated with

Rating

Programmatically deriving street geometry from address data does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Programmatically deriving street geometry from address data, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Programmatically deriving street geometry from address data will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3170045