Abstract
Utilities and public works departments use a number of different software packages for customer
service and facilities management. These systems include AM/FM/GIS, work management
systems (WMS), customer information systems (CIS), hydraulic models, and fixed asset
financial systems. Database integration is essential to achieving the full benefits of these
software tools.
Street locations are a critical piece of the integration puzzle. This paper explores technical issues
in the design of an integrated database that associates a street network and parcel base with street
names, address ranges, situs addresses, parcel IDs, and the locations of facilities, customers,
capital projects, and maintenance work.
Assumptions and methods
This paper is designed to raise database design issues that are of special interest to utilities and
public works organizations. The issues are important to anyone who ultimately needs to use the
database, but the paper is geared toward technical data modelers and database programmers.
The appropriate resolution of the issues in this paper will depend on an organization’s business
practices; there is no single “right way.” Possible approaches are suggested as a means to clari~
issues and provide a starting point for consideration of an organization’s unique requirements.
Figure 1 defines the conventions this paper uses to convey information about entity relationships.
The definitions describe the relationship of a left-hand entity to a right-hand entity.
Figure 1. Conventions for Describing Entity Relationships in this Paper
Refreshing locations on a street network
A street network is a database of physical attributes and addresses for a topologically connected
set of street segments. Each segment is identified in part by two endpoint nodes. The nodes
usually represent physical street intersections, but some may represent points at which there is a
change in the street’s physical composition, jurisdiction, or addressing rules. Figure 2 shows
endpoint nodes defining street segments. Typically, the “from” node represents the end of the
street with the lower address numbers. If this rule is not applied consistently, then the street
segment entity needs a separate attribute to indicate which end bears the lower number.
Figure 2 illustrates the difference between a conceptual street network and its location in space; a
street network can have multiple locations in space depending upon which map or survey is
being considered.
Figure 2. Street Segments, Street Network Nodes, and Coordinate Locations
People generally refer to a street segment by citing a street name and address block range. Street
naming and addressing rules can be complex. In order to accurately represent street network
locations, database designs should be flexible enough to accommodate the following phenomena:
- Multiple graphical components representing curved street segments
- Different street segments with identical endpoint nodes
- Duplicate street names and non-contiguous streets
- Alias street names
- Name and address discontinuities on a street segment
Multi Geographical Components Representing Curved Street Segments
When using AM/FM/GIS or CAD tools to create street centerlines, drafters may break curved
streets into multiple pieces to better represent the physical curves. These extra segments are
useful for visual representation. However, it is not necessary to create separate attribute records
for each small piece of street. In order to maximize data management efficiency, the segments in
a street network should define meaningful breaks in physical structure, jurisdiction, or addressing
rules. Figure 3 illustrates a logical distinction between street segments and the small pieces that
comprise their visual representations. This database design provides the option of linking street
segments to one or more graphic components.
Figure 3. Street Segments May Have One or More Graphic Components
