Different Street Segments with Identical Endpoint Nodes
When all streets are aligned in regular grids, the individual segments maybe uniquely identified
by their endpoint nodes. However, most communities have at least a handful of irregularly
patterned streets and circular drives that have the same endpoint nodes as other segments. If this
is the case, then the street segment key needs an additional component to augment the identi&ing
nodes. In Figure 1, the street segment entity is identifies by a three-part key: the “from” Node
ID, the “to” Node ID, and the Segment ID.
Street Name Normalization
In a normalized database, a street name is an entity, not an attribute of street segment. Figure 4
illustrates the basic concept. In most communities, the set of street segments associated with a
given name will occasionally be non-contiguous due to breaks in street alignments and
duplication of street names. In these situations, communities may want the ability to re-name
groups of street segments at some point in the future. (There area number of public safety
arguments and other reasons for eliminating the redundant street names.) By using a random ID
as the key and modeling the name itself as an attribute, an organization can create separate street
name instances to link to non-contiguous sets of street segments. The multiple instances may
carry the same name attribute at first, but the structure allows a local government to change the
name of one contiguous set of segments without creating a new entity instance and modi~ing the
associated street segment records. This structure also facilitates retention of a street name
history.
Figure 4. Street Name Entity Names a Set of Street Segments
Street name nomalization has a significant impact on data maintenmce productivity. Rather
than maintaining (and validating) street name text in myriad address records, an organization can
manage the data in a table or tables representing a separate street name entity. This concept
works when addresses are defined as the combination of structure numbers and fronting street
segments. (See Figure 5.)
As Figure 4 illustrates, a street name generally consists of a main street name, a type suffix (e.g.,
Avenue, Boulevard), a pre-directional (e.g., N, S, or NE before the main name) and a
post directional
(e.g., N, S, or NE after the type suffix).
Alias Street Names
In most communities, streets can have alternative names. These alternatives maybe historical
street names, or they may be numerical designators that appear on signage along with the official
names. By designing these “alias street names” into its database, an organization enables system
users to search and select data using common aliases. Street name aliases can be modeled in
many ways. If the alternative names generally pertain to the entire collection of segments
bearing a particular official name, then a one to many relationship can be modeled between a
street name entity and an alias entity. If aliases pertain frequently to subsets of the segments
associated with an official name, an organization may wish to create an associative entity that
links street segments with either an alias entity or the street name entity. In the latter case, the
street name entity would include instances of official street names and unofficial (alias) names.
Whichever approach is selected, the model should reflect the almost universal reality of streets
bearing multiple alternative names.
Name and Address Discontinuities on a Street Segment
If a street name or numbering scheme changes mid-block, it maybe useful to divide the street
into different network segments so that the name and number ranges can be properly represented.
Sometimes, street segments carry different names on opposite sides of the street. This may occur
when a street serves as a boundary between two local governments. Even if the street name is
the same, different numbering schemes may apply. One way to deal with this situation is to
create an entity for the segment’s “second side.” The second side entity would carry its own
address number range and its own relationship to street name (and potentially to street name alias
associations). This approach allows the organization to maintain a single logical segment while
preserving the flexibility needed to represent boundary streets. Alternatively, the two sides of the
street could be represented as separate street segment instances sharing common endpoint nodes
and a common set of street segment graphic components. (See Figure 3.) This approach requires
the use of a unique Segment ID to distinguish between the opposite sides of the street. (See
Figure 2.) When selecting an approach to this issue, it is usefi..d to consider pavement
management and dispatch processes. Even if the organization uses different networks for these
purposes, it maybe worthwhile to design consistent approaches to jurisdictional boundary
issues.
