September 1997 Number 218

Subject Area: IA Planning and Administration Responsible Senior Program Officer: Kenneth S. Opiela

A Generic Data Model for Linear Referencing Systems

This NCHRP digest describes the findings of NCHRP Project 20-27(2), Systems and Applications Architecture for GIS-T, conducted byAlan Vonderohe, Chih-Lin Chou, Forest Sun, and Teresa Adams, Department of Civil and Environmental Engineering,

The University of WisconsinCMadison. The digest was prepared by Kenneth S. Opiela, Ph.D., P.E.,NCHRP Senior Program Officer, from the contractor’s interim report.

INTRODUCTION

This digest describes a consensus locationreferencing data model that was developed underNCHRP Project 20-27(2), Systems and ApplicationsArchitecture for GIS-T. The model allows linkages tovarious types of data over all modes. This informationwill be of use to persons involved with the design andimplementation of field location referencing systemsas well as the structuring of agency databases forlocation referencing.

State departments of transportation (DOTs)have been adopting Geographic Information Systems(GIS) over the past decade with varying degrees ofintensity and success. DOTs manage vast stores oflinearly referenced data that must be associated withcartographic representations to be used in a GIS.Thus, there is a fundamental need for a generic datamodel for Geographic Information Systems forTransportation (GIS-T) to provide the linkage tolinear referencing components. Linear referencingsystems are used in nearly all application areas thatare based upon networks, including infrastructuremanagement, transit, freight, intelligent transportationsystems (ITS), waterway navigation, hydrologicalanalysis, utilities management, and seismologicalsensing.

BACKGROUND

Previous work on NCHRP Project 20-27 ledto the recommendation that transportation agenciesdevelop conceptual organizing principles foundedupon the notion of location as a data integrator(Vonderohe et al., 1993). Another result of NCHRPProject 20-27 was a suggested technologicalframework (server net) for support of GIS-T andtransportation computing in general. Genericfunctional and data models to complement thetechnological model developed in the initial projectwill be developed under NCHRP Project 20-27(3).

The significance of linear referencingmethods and systems to transportation applicationshas been recognized for some time. NCHRP Synthesisof Highway Practice 21, "Highway LocationReference Methods" (1974), made the distinctionbetween methods and systems, classified a number oflinear referencing methods, and maderecommendations for their improvement.Transportation agencies from time to time havestudied the location referencing methods they use andsought to adopt standards for them (Briggs andChatfield, 1987). During one study, the MichiganDOT identified 38 location referencing methods inuse by the agency. More recently, some state DOTs

2

CONTENTS

Introduction, 1

Background, 1

Workshop, 3Workshop Structure, 4Topic Areas and Issues, 4Key Concepts, 5

Data Model, 6Overview, 6Object Classes and Their Attributes, 6Associations and Their Attributes, 8Clarification of Directionality, 9Supported Operations, 10

Addressing the Issues, 10

Aspects of Implementation, 11Anchor Points and Intersections, 11Bi-Directional and Multi-Lane Facilities, 12Scalability, 12

Summary, 13Developments Since Publication of Initial

Results, 13

Discussion and Closure, 13

Bibliography, 19

3

have developed formal data models for locationreferencing (Deighton and Blake, 1993; Ries, 1993;Scarponcini, 1994; Rowell, 1996). Some havesucceeded in raising the issue to the policy level(Deighton and Blake, 1993). A number havedeveloped models and procedures for includinglinearly referenced data in GIS (e.g., Cihon, 1996).The Wisconsin DOT has recognized “location controlmanagement” as a formal business area in itsinformation strategy plan and developed rigorousprocedures for management of linearly referenceddata (WisDOT, 1996).

Early research in GIS in transportation led toidentification of the need for, and subsequentdevelopment of, dynamic segmentation as a criticalfunction for managing linearly referenced data(Fletcher, 1987; Dueker, 1987; Nyerges and Dueker,1988; Nyerges, 1990). More recently, the underlyingdata models that support current implementations ofdynamic segmentation have been examined (Dueker,1992).

An executive-level commitment to theconcept of a National Spatial Data Infrastructure(Mapping Science Committee, 1993) spurred interestin the development of standards and common modelsfor data. The Ground Transportation Subcommittee ofthe Federal Geographic Data Committeerecommended that a linear referencing system beincorporated in standards efforts. The FederalHighway Administration (FHWA) incorporated linearreferencing systems from the states in the HighwayPerformance Monitoring System (FHWA, 1993)

At the same time, a number of workersaddressed various aspects of the data conflationproblem, typically associated with attempts tointegrate census data tied to TIGER/line files withattribute data tied to other representations of the samestreet network that do not coincide with TIGER (e.g.,Brace and Peterson, 1994; Clark and Bain, 1994;Peterman, 1994; ).

Given all these activities and interests in datasharing and integration, the need for a common,generic data model for linear referencing systems wascompelling. Thus, a workshop was convened toaddress this need.

WORKSHOP

On August 5 and 6, 1994, 42 transportationprofessionals, systems developers, and academicsattended a workshop in Milwaukee, Wisconsin, with

the objective of preparing a draft consensusconceptual data model, at the entity-relationship level,for linear referencing systems. Workshopparticipants, selected for their expertise in linearreferencing systems and modeling, represented local,state, and federal transportation and mappingagencies; consultants, data providers, and softwareproviders from the private sector; and researchersfrom national laboratories and universities.Recognizing that it was not feasible to develop a datamodel that would meet all the needs of all applicationareas, a generic model was sought that met commonneeds and formed a core that could be extended asneeded in specific application areas.

The resulting draft data model, in objectmodeling form, associates transportation data withmultiple cartographic representations and multiplenetwork models through a single linear datum. Thedatum links the data model to real-world features andprovides the referencing space that enablestransformations among linear referencing methods,networks, and cartographic representations at variousscales. The data model supports a set of fundamentaloperations that cause data to flow between thedatabase world and the real world. The data model aspresented is intended to represent the requirementsfor a linear referencing model—it is not intended as aspecification.

A first-draft report was prepared from notesand other materials developed during the workshop,audio tape recordings of workshop sessions, andfollow-up discussions with workshop participants. Allparticipants were given the opportunity to review thefirst draft and provide responses. These responseswere assimilated to identify both consensus revisionsto the first draft and significant points of contention.The responders were informed of these results andasked to provide their opinions on each point ofcontention. The responders were also asked toprovide measures of the relative importance of theirpositions on each point of contention (i.e., “critical,”“strong preference,” “weak preference”). The revisedmodel presented in the second-draft report was true tothe model as developed during the workshop and tothe revisions on which there was consensus. Thesecond-draft report was presented and published inthe Proceedings of the 1995 AASHTO GIS-TSymposium in Sparks, Nevada (Vonderohe et al.,1995). Since that time, additional research, by boththe authors and other, independent researchers, hasled to refinements in the data model that areincorporated herein. Furthermore, the topic of

4

location referencing in general and linear referencingin specific has attracted a great deal of interest anddiscussion since the initial workshop. Implementationissues and methods for measurement system designare among the recently discussed ideas. Mostrecently, the TRB Task Force on GIS-T opened anunmoderated World Wide Web-based discussion onthe subject of linear referencing. Components of adialog, included in that Web-based discussion,between staff at the Bureau of TransportationStatistics (BTS) and the principal author of thisreport, are presented in the discussion section of thisdigest.

Since publication of the second-draft report,other researchers have discovered the need forrefinements in the data model that have beenincorporated herein. These researchers include DavidFletcher (Alliance for Transportation Research), whodiscovered a necessary refinement whenimplementing the model during Phase B of the GIS-TPooled Fund Study and Todd Hepworth (Universityof WisconsinCMadison), who when working with theprincipal author of this report (Vonderohe) onresearch funded by Sandia National Laboratories,independently discovered the same refinement asFletcher.

Wende O’Neill (Utah State University) andBruce Spear (BTS) conceived of a dialog on linearreferencing that is part of a World Wide Web-baseddiscussion. They developed the questions and adaptedthe responses of the principal author of this reportinto a Web-based discussion document, componentsof which have been subsequently freely incorporatedin this digest. Necessary clarifications and revisionsto some definitions, which became apparent duringdevelopment of the dialog, have also been adopted.

Workshop Structure

All participants received a package ofmaterials in advance of the workshop. The packageincluded information on the research project, theobjectives of the workshop, a preliminary program,and a set of pre-conference papers whose authors hadbeen asked to give presentations.

A modified form of the “Technology ofParticipation” method was used to structure theworkshop, with Professor Tim Nyerges of theUniversity of Washington serving as facilitator.Following introductory remarks concerning workshopmethods, 12 invited technical presentations weremade concerning various aspects of linear referencing

systems data modeling. During the presentations,participants identified issues and wrote them on largecards that were posted during breaks. Following thepresentations, participants were encouraged toidentify additional issues and post them. The issueswere then clustered into topic areas by the group as awhole. The clustered issues were then synthesizedand gaps were identified.

It was decided that the topic areas “Termsand Definitions” and “Scoping” were most critical todevelopment of the model, and a discussion of thesetopics by the group ensued. These discussionsultimately led to collective development of a linearreferencing system data model, which appeared in thefirst-draft report. The data model presented in thisdigest includes consensus revisions based onresponses to the first draft provided by workshopparticipants. It also includes refinements identified asnecessary through independent research since initialpublication of the second-draft report.

Topic Areas and Issues

Critical topic areas and issues identifiedduring the workshop included the following:

1. Terms and Definitions. Example issues:Standardized, unambiguous definitions must bedeveloped for common terminology. Terms suchas “traversal” should be used instead of “route,”“path,” or “trip,” all of which might be subclassesof “traversal.” Terms such as “anchor point” and“anchor section” should be used because “controlpoint” and “control section” have other meanings.The term “distance” can mean “odometerdistance,” “posted distance,” or “cogo distance.”

2. Scoping. Example issues: Are geographic,spatial, cartographic, and temporal objectsmodeled in the same domain? What is theconceptual extent of the term “linear referencingsystem”? Is there a set of core requirements for ahost of applications? We must account for vector,non-planar models used in commercial GIS. Whatare the primary functions that must be supported?Is linear referencing broad enough to addressworkshop goals?3. Schema Constructs. Example issues: What arethe primary building blocks of linear referencingmethods? What are the differences betweenstructural data model requirements and functional

5

views? Are linear referencing system componentshierarchical objects or interdependent andrelational? We must relate topology, one-dimensional, two-dimensional, and three-dimensional space. Can one conceptual data modelaccommodate feature-based systems, planar graph-based systems, and non-planar graph-basedsystems?

4. Transformation. Example issues: How do weuniquely and unambiguously identify locations fortransforming that information between dissimilarinformation systems? What are the basictransformations between linear referencingmethods? How do we link multiple linearreferencing methods together for data integrationin the network domain? What are the rules foraggregation to support more generalizedreporting?

5. Multi-Dimensionality. Example issues: Toaddress conflation, (1) should we develop uniqueidentifiers for certain features; (2) should westandardize on topology or geometry (x,y,z)? Dowe need a Global Positioning System (GPS)/GISlinkage? Linear referencing systems must belinked to higher-dimensional systems, includingthose that model time. Spatial proximity is not asurrogate for network topology.

6. Methods and Coding. Example issues: Howare the “lowest common denominator” sitesidentified? What is the appropriate datumstructure? What is meant by the “location” of abridge—is it the center, one end, the other end?The model must be able to handle very largedatabases. What are the rules for establishinglinear referencing method starting and endingpoints? What is the best method for referencingramps? What geographic features are assignedexternal identifiers?

7. Data Integrity. Example issues: How do weensure data integrity if we have multiple linearreferencing methods? What are the referentialintegrity rules? Can versions be coordinated byadding version numbers to unique identifiers?What are the implications of alignment changes?

8. Institutional Policy. Example issues: Do usersneed to understand linear referencing systems?What policies and procedures are required for a

linear referencing system? What cost constraintsare associated with a linear referencing system?

Key Concepts

NCHRP Synthesis of Highway Practice 21contains two fundamental premises adopted by theworkshop participants:

1. There is a clear distinction between linearreferencing methods and linear referencingsystems: “A highway location reference system is aset of office and field procedures that includes ahighway location reference method. The latter is away to identify a specific location with respect to aknown point.” The workshop participants includedwithin the concept of system a means fortransformation among various methods. Thus,“milepoint,” “reference post,” and “engineeringstationing” are methods. The policies, records, andprocedures that relate these methods are thesystem.

2. The location of any unknown point along alinear feature can be determined by specifying thedirection and distance from any known point to theunknown point. All linear referencing methods arebased on this. The workshop participantsconcluded that the premise is true for two andthree dimensions also. Each additional dimensionremoves a constraint on direction.

It was concluded that the time limitations of theworkshop precluded development of a data model thatsupported all the needs of all possible applicationareas. Therefore, a core, generic data model wassought that could be extended to meet specific needsof various applications. Additionally, a model thataddressed the requirements for linear referencingsystems was pursued rather than a robust and elegantspecification.

Multiplicity became a theme. There is a centralneed to integrate not only multiple scales ofgeography and cartographic (coordinate-based) data

6

from multiple sources, but also multiple networkmodels, each of them necessary for particularapplications.

It was decided that the data model must supportthe following fundamental operations:

1. Locate. Establishment of the location of anunknown point in the field by reference to objectsin the “real world.”

2. Position. Translation of a real-world locationinto a database location.

3. Place. Translation of a database location into areal-world location (the inverse of the “position”operation).

4. Transform. Conversion between various linearreferencing methods, represented by databaselocations; between various cartographicrepresentations; and between methods andcartographic representations.

It was expected that if these operations are supported,then the model should support higher-level operationssuch as those associated with GIS (e.g., overlay,connectivity, proximity) and those associated withnetwork analysis (e.g., pathfinding, routing, location,and allocation).

DATA MODEL

Overview

Figure 1 presents a conceptual overview of thedata model. The central notion is that of a lineardatum that supports multiple cartographicrepresentations (at any scale) and multiple networkmodels (for various application areas). The datumprovides the fundamental referencing space fortransformations among various linear referencingmethods, network models, and cartographicrepresentations. It also links the model to the “realworld” through attributes that describe its locationand spatial characteristics in real-world referencesand measures.

Cartographic representations provide coordinatereferences, the basis for to-scale visualization of themodel, and linkages to two-dimensional and three-dimensional GIS databases. Network models providethe topological framework for pathfinding, routing,

location/allocation, transshipment, and flowoperations.

A number of linear referencing methods might beassociated with each network model. These methodsmight be those associated with infrastructuremanagement, such as reference post, milepoint, orengineering stationing. They might also be thoseassociated with navigation (requiring recognizablelandmarks or navigation aids), or with transit (timingpoints), or with a host of other application areas. Eachlinear referencing method ties a collection of businessdata to the model, thereby providing a means forintegration of those data. The linear referencingsystem can be thought of as all those components ofthe model that provide methods for locationreferencing of business data, transformations amongthose methods, and linkage of the model to the “realworld” and its cartographic representations.

The object model diagram appears in Figure 2.The diagramming method is slightly modified fromthat of Rumbaugh et al. (1991). The modificationbeing that low and high cardinalities are shown withArabic numerals on both ends of all associations.Standard notation includes the name of an objectclass in the upper half of a rectangular box; attributesof the class in the lower half of the same box; anassociation between two object classes denoted by aline connecting the boxes; an association descriptorwritten on the connecting line for all associationsexcept aggregations; attributes of an associationappearing in the lower half of a rectangular box tiedto the association's connecting line by a half loop;“many” cardinality indicated by a filled circle; “zeroor one” cardinality indicated by an empty circle;“exactly one” cardinality indicated by lack of a circle;and aggregation indicated by a diamond symbol.

Object Classes and Their Attributes

Linear Datum. The complete set of anchorsections and anchor points, constituting a mutuallyexclusive, totally exhaustive, ordered set of linearlocations1 (see Figure 3). The linear datum relates thedatabase representation to the real world and providesthe domain for transformations among linearreferencing methods and among cartographicrepresentations. There is a single linear datum. It isincluded in this data model because of the centrality 1 Definition derived from personal communication with David Fletcher(March 1997).

7

of its concept to the overall model, not because therewould necessarily be a number of instances thatwould have to be tracked in a database. Variousversions of the linear datum might exist over time aschanges in transportation facilities occur. Noattributes are assigned to the linear datum.

Anchor Point. A zero-dimensional location thatcan be uniquely identified in the real world in such away that its position can be determined and recoveredin the field. Each anchor point has a “locationdescription” attribute that provides the informationnecessary for determining and recovering the anchorpoint's position in the field. Forms of locationdescriptions can vary and can be quantitative ordescriptive or both, (e.g., the intersection of thecenterlines of Oak Street and Maple Street; and 1.2miles south of the Post Office on the centerline ofRoute 9).

Anchor points can be understood as one-dimensional control points, in that they serve thesame purpose as geodetic control points in two andthree dimensions. That is, they are the fundamentalobjects to which all other objects are directly orindirectly tied.

Anchor Section. A continuous, directed,nonbranching linear feature, connecting two anchorpoints, whose real-world length (in distance metrics),can be determined in the field. Anchor sections aredirected by specifying a “from” anchor point and a“to” anchor point. Anchor sections have a “distance”attribute, which is the length of the anchor sectionmeasured on the ground. Values are expressed inunits of linear distance measure (e.g., kilometers).

Anchor sections provide the fundamentalreferencing space. The collection of anchor sectionsin a given linear referencing system is analogous tothe ellipsoid surface in a geodetic datum or the mapprojection surface in a two-dimensional Cartesianreferencing system.

Cartographic Representation. A set of lines thatcan be mapped to a linear datum (see Figure 4). Theset of lines can be either fully or partially linked. Thatis, the set can consist of disjoint groups with the linesin each group being internally linked. Cartographicrepresentations have a “source” attribute that denotesthe source (scale and lineage) of the object. Scalevalues are expressed as ratios or as equations thatrelate distances measured on the source form of the

cartographic representation to distances measured onthe ground.

Cartographic representations provide coordinatereferences; the basis for to-scale visualization of othercomponents of the linear referencing system model;and linkages to extended topological, vector- basedGIS data models.

Line. “A generic term for a one-dimensionalobject” (USGS, 1992). Spatial Data TransferStandard (SDTS) goes on to define five specific kindsof lines: (1) line segment, (2) string, (3) arc, (4) link,and (5) chain. A line, as defined herein, can be any ofthese except a link. This is because lines, as definedherein, have a “shape and position” attribute.According to SDTS, a line segment is a direct linebetween two points, a string is a connectednonbranching sequence of line segments, an arc is alocus of points that forms a curve that is defined by amathematical expression, and a chain is a directednonbranching sequence of nonintersecting linesegments and (or) arcs bounded by nodes, notnecessarily distinct, at each end. Shape and positionare provided either by the x,y,z coordinates of pointsassociated with line segments or by the mathematicalexpressions associated with arcs. Possibilities fortypes of coordinate values include Cartesian andgeographic (lat/long/elev). Possibilities formathematical expressions include splines andpolynomials.

Network. A graph without two-dimensionalobjects or chains. If projected onto a two-dimensionalsurface, a network can have either more than onenode at a point and (or) intersecting links withoutcorresponding nodes. Note: This is a modification ofthe definition provided by the SDTS. Modification isnecessary to exclude chains. Within the context of thelinear referencing system data model, a network is anaggregate of nodes and links and is, thus, a purelytopological object (see Figure 5). The networkcomponent of the model provides the basis foranalytical operations such as pathfinding and flow.No attributes are assigned to networks.

Node. A zero-dimensional object that is atopological junction of two or more links, or an endpoint of a link. Note: This is a modification of thedefinition provided by the SDTS. Modification isnecessary to remove reference to chains. In this datamodel, nodes do not have coordinates. They arelocated geometrically by reference to the datum.

8

Each node has a “datum measure” attribute that isused to locate it on an anchor section. “Datum meas-ure” is an offset measured from the “from” anchorpoint of the anchor section. “Datum measure” is ex-pressed as a distance measure in the same units as the“distance” attribute of the associated anchor section.

Link. A topological connection between twoordered nodes. Note: This is a modification of thedefinition provided by the SDTS. Modification isnecessary to require directionality. Each link has a“weight” attribute that is a linear measure ofimpedance associated with travel along the link.Weights are often expressed in distance measure, butthey could be in other linear metrics such as traveltime or cost.

Linear Referencing Method. A mechanism forfinding and stating the location of an unknown pointalong a network by referencing it to a known point.Note: This is a modification of the definition providedby Deighton and Blake (1993). There are many kindsof linear referencing methods (e.g., milepoint,reference post, and engineering stationing). All linearreferencing methods consist of traversals andassociated traversal reference points that togetherprovide a set of known points, a metric, and adirection for referencing the locations of unknownpoints (see Figures 6 and 7). No attributes areassigned to linear referencing methods.

Traversal. An ordered and directed, but notnecessarily connected, set of whole links. Codingconventions are required for establishing traversaldirectionality (in contrast to link directionality) andfor specifying nonconnected traversals. No attributesare assigned to traversals. Note: It was the intent ofthe workshop participants to allow dendritictraversals, but specific implications of this for themodel have not been investigated.

Traversal Reference Point. A zero-dimensionallocation along a traversal that is used to referenceevents along the traversal. Each traversal referencepoint has a “traversal measure” attribute, which isused to locate it along the traversal. “Traversalmeasure” is an offset measured from the initial nodein the traversal to the traversal reference point. It is inthe same units as the “weight” attribute of the links inthe traversal.

Point Event. A zero-dimensional phenomenonthat occurs along a traversal and is described interms of its attributes in the extended database (seeFigure 8).

Examples of point events include signs andaccidents. Each point event in the linear referencingsystem data model has a “traversal measure” attribute.“Traversal measure” is an offset measured from thereferenced traversal reference point to the point event.Point event traversal measures are in the same units asthe traversal measures of the traversal referencepoints that they reference. A positive point eventtraversal measure expresses measurement in thedirection of the traversal. A negative point eventtraversal measure expresses measurement against thedirection of the traversal. Point events will typicallyhave additional attributes in the extended database.

Linear Event. A one-dimensional phenomenonthat occurs along a traversal and is described in termsof its attributes in the extended database (see Figure8). Examples of linear events include pavement types,speed zones, and construction projects. Each linearevent in the linear referencing system data model has“start traversal measure” and “end traversal measure”attributes that locate the linear event along thetraversal. The traversal measures are offsets measuredfrom the traversal reference points that theyindividually reference. Linear event traversalmeasures are in the same units as the traversalmeasures of the traversal reference points that theyreference. Rules for direction of measurement areidentical to those of point event traversal measures.Linear events will typically have additional attributesin the extended database.

Associations and Their Attributes

An anchor section goes from an anchor point toan anchor point. Each anchor section is associatedwith two, not necessarily distinct, anchor points inthis way. Any number (0,N) of anchor sections can gofrom or to a given anchor point.

A link goes from a node to a node. Each link isassociated with two, not necessarily distinct, nodes inthis way. At least one link must go from or to a givennode.

A traversal reference point must be on one andonly one traversal. A traversal can have any number(0,N) of traversal reference points on it.

A point event must reference one and only onetraversal reference point. A traversal reference

9

point can be referenced by any number (0,N) of pointevents. A linear event must (1) reference its startpoint to one and only one traversal reference pointand (2) reference its end point to one and only onetraversal reference point. The traversal referencepoints that are referenced for the start and end of alinear event do not necessarily have to be distinct. Atraversal reference point can be referenced by anynumber (0,N) of linear events.

A number of aggregation associations appear inthe model. The linear datum is composed of at leasttwo, not necessarily distinct, anchor points and atleast one anchor section. A cartographicrepresentation is composed of at least one line. Anetwork is composed of at least one link and at leasttwo, not necessarily distinct, nodes. A linearreferencing method is composed of at least onetraversal and at least one traversal reference point.A traversal is composed of at least one link. Thelinks are ordered in this association, thereby, givingdirection to the traversal (see Figure 6). A link canbe a component of many traversals (see Figure 7).

A cartographic representation can representzero or one linear datum. The linear datum can berepresented by any number (0,N) of cartographicrepresentations (see Figure 9). A line can representany number (0,N.N) of anchor sections, including asmany as two partial anchor sections (see Figure 10). An anchor section can be represented by any number(0,N.N) of lines, including as many as two partiallines. The lines are ordered and the association isassigned attributes to resolve the many-to-many andpartial-object mappings. The association“represents,” between line and anchor section, has“from position” and “to position” attributes. “Fromposition” specifies the percentage of the first line inthe list to be used as an offset from that line's startpoint to map the beginning of the anchor section ontothat line. “To position” specifies the percentage of thelast line in the list to be used as an offset from thatline's start point to map the end of the anchor sectiononto that line.

A network is referenced to zero or one lineardatum. The linear datum can have any number (0,N)of networks referenced to it (see Figure 11). A nodecan be on zero or one anchor section. An anchorsection can have any number (0,N) of nodes on it (seeFigure 12). A link lies along any number (0,N) ofanchor sections. An anchor section can have anynumber (0,N) of links lying along it. The association“along,” between link and anchor section, has a“directed sequence” attribute. The attribute specifies

the sequence of anchor sections along which a linklies and the concurrence or contrariness of thedirection of the link and the direction(s) of the anchorsection(s). This association is required to eliminateambiguities that can arise in its absence (Fletcher,1995; Vonderohe and Hepworth, 1996).

A linear referencing method must reference datato at least one network. A network can have anynumber (0,N) of linear referencing methods thatreference data to it (see Figure 13).

Clarification of Directionality

Figure 14 depicts the components of the modeland a mapping that produces displayable coordinatesfor business data. Three object classes in the modelhave direction associated with them.

Each anchor section has direction, by definition.The direction of an anchor section could be initiallyestablished in any way, perhaps as a matter ofconvenience in the field. Anchor section direction isused to map lines and nodes onto anchor sections andto map anchor sections onto links.

Each link has direction because the order of thenodes it connects is specified. Link direction might beestablished according to the application the links willsupport. Link direction is used to map links ontoanchor sections and to support network analysis.

Each traversal has direction, by definition.Traversal direction might by established byinstitutional factors (e.g., STH 10 South) or byanalysis (e.g., pathfinding). Traversal direction isused to order traversal reference points and to mappoint events and linear events onto traversals.

Within the model, these three kinds of directionare reconciled by ordering and specifying “from/to”associations. Anchor section direction is establishedby specifying “from” and “to” anchor points. Linkdirection is established by specifying “from” and “to”nodes, then reconciled with anchor section directionby specifying a directed sequence of anchor sectionswhen mapping links to anchor sections. Linkdirection is reconciled with traversal direction byordering the links that compose the traversal.Supported Operations

Using information from an implementation of thismodel, one can locate oneself in the field by firstidentifying which anchor section one is on (from ahardcopy cartographic representation or a listing ofanchor sections, their anchor points, and the location

10

descriptions of the anchor points). A measurementwill then be made, along the linear facility, from the“from” anchor point, toward the “to” anchor point, tothe unknown point, thus establishing its location.

A phenomenon (say, an accident) in the field canbe positioned as a point event in the database merelyby creating a record that identifies the traversalreference point to which the accident is referencedand specifies the traversal measure (+ or !) from thetraversal reference point to the accident. The recordwill usually also contain values for other attributes ofthe point event (accident).

A point event in the database can be placed in thefield by first using the traversal measure of the pointevent and the traversal measure of the associatedtraversal reference point to compute a cumulativeoffset from the initial node in the traversal to the pointevent. Then compute cumulative offsets from theinitial node in the traversal to successive nodes in thetraversal (using link weights) until a node is reachedwhose cumulative offset is greater than thecumulative offset of the point event. This node andthe immediately previous node determine the link onwhich the point event lies. From the cumulativeoffsets, compute the offset of the point event from the“from” node of the link as a percentage of the weightof the link. Using the link/anchor section associationand the node/anchor section associations determinethe anchor sections and/or portions thereof that mapto the link. Determine the length of the link from thedistance attributes of the anchor sections. Computethe distance from the mapped location of the link's“from” node to the point event using the percentageoffset and the length of the link in distance units.Determine the anchor section that contains the pointevent and compute the distance from that anchorsection's “from” anchor point to the point event.Produce a hardcopy cartographic representation andprint out the location description of the “from” anchorpoint. Discover the “from” anchor point in the fieldand, using the cartographic representation fordirection reference, lay out the distance to thephenomenon represented by the point event.

A milepoint reference can be transformed into aproject/engineering stationing reference on the sametraversal by first comparing each project's “beginningof job” or “0+00” traversal measure to the traversalmeasure of the milepoint. If the milepoint is on anyproject, it will be on the project whose 0+00 has thelargest traversal measure that is less than the traversalmeasure of the milepoint (here it is assumed that allproject directions are the same as that of the

traversal). For the selected project, determine if the“end-of-job” traversal measure is greater than thetraversal measure of the milepoint. If so, themilepoint is on the project. Compute the offset from0+00 to the milepoint. Express the result asengineering stationing.

ADDRESSING THE ISSUES

A brief synopsis of how the model addressesissues identified by workshop participants follows:

1. Terms and Definitions. A data dictionary isincluded with the model. Definitions from theliterature, particularly the SDTS were usedwhenever possible. Terms having alternativemeanings or interpretations in the transportationand GIS communities were avoided.

2. Scoping. The scope of the model is linearreferencing. Primary spatial aspects of the modelare topology in networks, distance measures in thelinear datum, weights in networks, and offsets tolocate zero-dimensional objects. The modelincludes cartographic representations in higherdimensions to provide coordinate references, to-scale visualization, and linkages to extended GISdata models. Issues such as polygonalrepresentation of facilities at large scales andleft/right offsets to off-facility features are notdirectly addressed by the model, but could betreated in extensions. Four fundamental operationsare supported. Many other higher-level operationsare also certainly supported. Temporaldimensionality remains unaddressed, except for afew ideas on versioning (see item 7, below). Thedevelopment of robust space/time abstractions isan open research area.

3. Schema Constructs. The model wasdeveloped to be generic and to include the core

11

requirements of as many application areas aspossible. The model is presented as an objectmodel. Considering the sparseness of behaviorincluded in the model, a relational form should bereadily derivable. No hierarchies of classes areincluded in the model as presented. The model hascomponents that are non-planar (networks) andcomponents that are planar in manyimplementations (cartographic representations).

4. Transformation. Transformation is one offour fundamental operations demonstrated to besupported by the model. Transformations arepossible between linear referencing methods,between cartographic representations, and betweenlinear referencing methods and cartographicrepresentations. Aggregation of events to supportmore generalized reporting should be supported bythe model, although no demonstration is provided.

5. Multi-Dimensionality. The linear datum isthe fundamental reference space fortransformation, for linking to higher dimensions,and for solving the conflation problem. It is atopological object that includes distance measures. Proximity operations can take place at the lineardatum level if distance is the desired metric, at thenetwork level if link weight is the desired metric,or at the cartographic representation level if two-or three-dimensional analysis is desired. Use ofGPS during data collection essentially provides anew cartographic representation of a linear facilityfor each pass in the field. Such data can be linkedto the model by associating receiver positions withanchor points as they are encountered in the field.

6. Methods and Coding. The “lowest commondenominator” is the linear datum. It consists ofanchor points and anchor sections. Anchor pointsare zero-dimensional objects that must beunambiguously identifiable in the field. Therefore,a bridge cannot serve as an anchor point. Thecenter point of a specified end of the deck of aspecified bridge could serve as an anchor point.Starting and ending points of traversals are theappropriately ordered nodes of the first and lastlinks in a traversal. The representation andreferencing of ramps connecting roadways is notdirectly addressed by the model, but could be withextensions. Which geographic features areassigned external identifiers depends to someextent upon applications. The only features that

require external identification are anchor points.Most applications would require identifiers fortraversals and traversal reference points, at aminimum. The efficiency of the model forsupporting operations on very large databasesremains unknown. It should be remembered thatthe model is not intended as a specification.Refinements are possible.

7. Data Integrity. The model solves many dataintegrity problems arising from multiple copies ofdata. For example, linear referencing methods donot have to be explicitly imbedded in multiplecartographic representations. There is a singlelinear datum. Changes in the linear datum, causedby changes in alignment, generate a cascade ofchanges in the database (for mappings between thelinear datum and cartographic representations, formappings between the linear datum and networks,for specification of traversals, and for offsets oftraversal reference points and events). Rules thatassociate these necessary changes must bedeveloped. Temporal objects could be createdthrough the use of version identifiers. Withappropriate rules for assembly of temporal objects,they could be used to track changes over time.

8. Institutional Policy. The greatest incentivefor policy concerning linear referencing systems iscost savings realized from data integration, datasharing, and reduction of chaos. Some agencieshave already adopted policy in this regard (e.g.,Utah). Use of a linear referencing system must besimple and straightforward. Even so, not all usersmust understand the use of all methods. Easilyunderstood procedures must be developed for usein both the field and the office.

ASPECTS OF IMPLEMENTATION

Anchor Points and Intersections

Anchor points are not necessary at even-valenceintersections. Such intersections can contain anchorpoints, but they are not required to. Any two anchorsections can cross without sharing an anchor point.Each odd-valence intersection must include an anchorpoint. However, all but one anchor section can passthrough such an intersection without including theanchor point. This characteristic reduces the numberof linear datum objects to be developed, managed,

12

and maintained. It also places a lower bound on thenumber of anchor points required in the linear datum.The minimum number is the sum of the number oftermini and the number of odd-valence intersections.However, other design considerations, such as therequired accuracy of the underlying system ofmeasurements, can cause the number of anchor pointsto increase beyond this theoretical minimum.

Bi-Directional and Multi-Lane Facilities

Choices must be made for representing bi-directional facilities. At the network level, individuallinks represent each direction of travel. The issue isthe number of required anchor sections. A singleroadway, having two directions of travel, can berepresented by a single anchor section. This choiceresults in a minimum number of datum objects andhas the further advantage that any individual object inthe field (real world), serving as a reference point fortraversals in both directions, has a single datumlocation. An example of such an object is theintersection of a roadway centerline with an edge of abridge abutment. With this choice, spatial distinctionsamong events must be maintained at the link ortraversal level. Otherwise, events of the same kind,which should be associated with opposite directionsof travel, risk having the same offset along the singleanchor section.

A single roadway, having two directions of travel,can be represented by two anchor sections (one foreach direction). This choice has the advantage thatspatial distinctions among events can be maintained atthe linear datum level. Disadvantages includedoubling the number of anchor sections anddeveloping and maintaining two linear datumaddresses for any single object in the field that servesas a reference point for traversals in both directions.

Two anchor sections are necessary in the unlikelyoccurrence of a single roadway with opposite traveledways whose lengths differ by an amount large enoughto require their resolution. A similar statement can bemade for representation of multiple lanes in a singledirection. Information on events at the lane level isuseful for construction and emergency vehiclerouting, signal timing, congestion management, andother operational functions and ITS applications. Fohlet al. (1996) propose representing roadwaycenterlines as continuous linear spatial objects withstart and stop points for lanes located by offsets alongthem. They argue that theoretical and technologicallimitations on the accuracy of absolute positioning

obviate the need for explicit spatial representation oflanes. In fact, the potential accuracy of relativemeasures, such as lane length, might be great enoughto make metric distinctions among lanes, but the needfor doing so from an application perspective probablydoes not exist.

A divided highway with separate roadways foreach direction of travel requires an anchor section foreach roadway. The anchor sections terminate atdistinct anchor points and often have different valuesfor the distance attribute. Distinct objects in the fieldserve as reference points for traversals along theindividual roadways.

Scalability

Scalability is traditionally an issue of cartographicrepresentation and how spatial abstractions areaffected by display at different scales. Much researchhas been done on map generalization and methods fortransforming maps from larger to smaller scales. Alinear referencing system has a certain level ofabstraction, but it has no single cartographic scale. Infact, it has as many cartographic scales as there arecartographic representations with distinct sourcescales linked to it. This aspect of scalability of alinear referencing system is manifested in the one-to-many association between linear datum andcartographic representation.

A divided highway, represented by two anchorsections, might appear as a single line on a small scalemap and as two lines on a large scale map. Theanchor sections would both be associated with thesingle line for display at small scale. Each of themwould be associated with an individual line fordisplay at large scale. Two point events, each with alinear datum address in a separate anchor section,would appear to be co-linear at small scale and indifferent lines at large scale. The Wisconsin DOT hasan effective demonstration of this characteristic of theRies (1993) link/site model (Ries, 1995).

Zero-dimensional objects in the linear referencingsystem data model (e.g., anchor points and traversalreference points) are zero-dimensional objects on theground (e.g., intersections of centerlines). Distancesin the data model are distances as measured on theground. Spatial abstraction takes place at the one-dimensional level. Roadways, pavements, and manyof the things that happen along them (events) are two-and three-dimensional, yet they are represented ashaving linear locations. The second and thirddimensions are sometimes represented as attributes

13

(e.g., pavement width and thickness). In this manner,the linear referencing system is similar to a surfacemodel that represents elevation as an attribute ofhorizontal location.

Should single roadways with travel in bothdirections be modeled by one anchor section and twoanchor points, two anchor sections and two anchorpoints, or two anchor sections and four anchor points?The answer lies in what we are truly trying torepresent and what level of the model we select formaintaining spatial distinctions. The former must beaddressed from an application perspective. The lattermust be addressed from a data managementperspective.

SUMMARY

A generic data model for linear referencingsystems has been developed. The model includesmultiple cartographic representations, multiplenetworks, and multiple linear referencing methods towhich any amount of business data can be tied. Themodel supports integration of attributes attached tovarious spatial databases without requiringregistration of cartographic representations incoordinate space. Instead, they are all linked to asingle common linear datum.

The model supports a set of fundamentaloperations that links the database world and the realworld and allows transformations within the databaseworld. The model will also support network analysisand basic GIS operations, although examples have notbeen developed.

The model is intended as a description of the corecommon requirements of as many application areas aspossible. A need for extension of the data model toinclude particulars for specific application areasshould be expected. Potential application areasinclude infrastructure management, transit, freight,ITS, urban planning, waterway navigation, andseismological testing.

Developments Since Publication of Initial Results

Since the workshop, interest and activityassociated with linear referencing systems hasincreased. FHWA is supporting development of a“best practices” manual for linear referencing. TheITS community is striving for standards and a genericdata model for linear referencing (Siegel et al., 1996).The GIS-T Pooled Fund Study Team adapted the data

model reported herein during Phase B of theirresearch (Fletcher, 1995) and developed a linearreferencing engine as proof-of-concept for the datamodel. A number of standards efforts includeconsideration of linear referencing (Hickman, 1995;Scarponcini, 1995). Systems have been developed toaddress the conflation problem (Siegel, 1995; Brownet al., 1995).

Implementation issues have been examined(Sutton and Bespalko, 1995). The workshop datamodel has been extended (Dueker and Butler, 1997).A methodology for design of the field component oflinear referencing systems has been developed(Vonderohe and Hepworth, 1996). A call has comefor development of a unified linear referencingsystem with a common linear datum to support thetransportation and navigational data needs of civiliangovernment, the military, and the private sector(Fletcher et al., 1996). BTS has hosted a World WideWeb-based discussion of linear referencing issues forthe GIS-T Task Force of the Transportation ResearchBoard. A dialog between Wende O’Neill of UtahState University, Bruce Spear of BTS, and theprincipal author of this digest serves as theconcluding section of the digest.

DISCUSSION AND CLOSURE

The following questions and comments fromO’Neill and Spear and answers and comments fromVonderohe are intended to clarify and elaborate onaspects of the linear referencing systems data model,to address issues raised subsequent to publication ofthe workshop report, and to explore some practicalaspects of implementation of the model.

Question 1: According to the definition of“anchor point,” forms of location descriptions canvary and be quantitative or descriptive or both. If weuse only a named road description for an intersection,then it is likely that some anchor points have the samedescription. Is this a problem? Don't we have to attachadditional information, such as a coordinate point or adirection (N,S,E,W)?

Answer: Yes, it is certainly a problem if we useonly named roads in most cases. According to itsdefinition, an anchor point must be uniquelyidentifiable and recoverable in the field. A locationdescription that does not fulfill this characteristic isinsufficient and cannot be used. No description is

14

really adequate for actual implementation unless itclearly and unambiguously defines the location of apoint for people using the description in the field.Anchor points are actually points, so we shouldprobably be saying something like “The intersectionof the centerlines of the traveled ways at thesouthwestern most of two intersections of BonnieBranch Rd. & Bonnie Acres Dr.” We makemeasurements of distances between these points, sothey must be points.

Question 2: How do we define anchor sections?Using the named route notion (all road segments withthe same name belong to a route) and the conceptsdescribed above to define anchor sections, design ofthe anchor sections ensures that an anchor point isnever the “from” anchor point for more than oneanchor section. The definition of node impliesknowledge of the anchor section for which the lineardatum measurement is relevant. However, it shouldbe explicitly stated that if anchor points are notuniquely used as “from” points on a single anchorsection, then the node records must contain explicitreference to the anchor section. This solves themultiple path problem.

Answer: There is no need to keep anchor pointsfrom being the “from” anchor point for more than oneanchor section. Anchor points and anchor sections arenot restricted in this way. Two or more anchorsections can share a common anchor point—and thatanchor point can be the “from” anchor point for all ofthem (but it doesn't have to be; it could be the “to”anchor point for some of them). Anchor sections canhave common anchor points, but they cannot overlap.The direction of each anchor section is totallyarbitrary. That is because their sole purpose is toserve as the basis for locating other things.

The model requires explicit reference of nodes toanchor sections because there would be ambiguitywithout it. The object model diagram in Figure 2includes a direct association between nodes andanchor sections. This would manifest itself as apointer from a node to an anchor section. Since theanchor section knows which anchor point is its“from” anchor point, the node can be located alongthe anchor section.

Question 3: In designing the linear datum, youfirst define your points, then the lines connectingthem correspond to existing road facilities. With a

network, you first define your connections (flows ofinterest), then the points are self-evident.

Answer: The linear datum is similar to a networkin some ways, but it is different in at least one veryimportant way. Flows are of no concern in designingthe datum. The datum does not tell us how to get from“here” to “there” like a network does. It just tells uswhere things are. There are no routes or traversals inthe datum.

Each anchor section represents a single real object(e.g., a section of roadway) and that real object isrepresented by a single anchor section. Any real thinghas one and only one true location at any point in time(unless it is a quantum particle or something). Thepurpose of the linear datum is to provide a basis fordescribing the unique locations of things.

Question 4: Using anchor sections with calibrateddistances between each adjacent pair of intersectionsresults in higher accuracy in placing linearlyreferenced events along a cartographic line. Basically,the error is spread over a shorter distance. Anchorsections that stretch from one county boundary toanother or one state boundary to another (like I-15between the Idaho border and the Arizona border),with no calibration points in between, will result insubstantial error in trying to place a linear event. Accuracy in placing events along a centerline will bemore of a problem in rural areas, where the distancebetween anchor points is greater, and on very curvyroads. However, the extreme opposite representation,a calibrated anchor section between each pair ofintersections, brings back the multiple route problemwhose solution is to reference the anchor section witha name descriptor.

Answer: Two important points of discussion areraised above:

1. Do we have to agree on names of roads in orderto identify anchor sections? I vote a resounding“No”! What we need to agree on is a set of neutralidentifiers—one for each anchor section. Then,everyone can associate whatever names they wantwith the identifiers (and, thereby, the anchorsections). This way, if the Municipal Managerwants to call the roadway in front of my house“Main Street” and the DOT wants to call it“Highway 51,” they can both have their way andstill be able to share data. The events that they areinterested in are happening along the

15

roadwayCand there is only one roadway, eventhough they refer to it by different names. Thoseevents of interest will be located by offsets alongthe same individual anchor sections representingthat roadwayCfor both the Municipal Managerand the DOT. Road names and routes (traversals)change too often and different parties andauthorities use different ones of them to identifythe same thing.

2. What is the optimum length of an anchorsection? This is a question that I think should bevigorously debated in order to identify all thefactors and the weights that should be given toeach of them as they contribute to the answer. It isone of a few questions at the heart of the linearreferencing system design problem. Another, forexample, is “What is the required accuracy ofanchor section distance measures?” The answersto these, and a few other key questions determinethe optimum configuration of the linearreferencing system in the field. By “optimum,” Imean the least-cost configuration that meets theaccuracy requirements of its users. A method forfinding the answers to these questions is what thereport to Sandia Labs is about (Vonderohe andHepworth, 1996).

I will now put in my two cents' worth: I thinkthe factors that are most important in addressingthis question have to do with linear referencingand not cartographic representations. When we dolinear spatial analysis (e.g., routing, allocation, tripassignment), we are concerned with the accuraciesof linear locations, not x,y locations. (As an aside,I believe that the primary reason we need a linearreferencing system is to do linear spatialanalysis—I mean this in a broad sense—not justpathfinding, etc.). For example, a pavementmanagement application can be very effective byoperating only on linear data, without everreferencing two- or three-dimensional data. So theaccuracy needed here is in linear locations. Now,if the pavement manager wants to display theresults on a map, we need to be concerned with theaccuracy of relationships between linear andcartographic data for visualization, not analyticalpurposes. This does not mean that accuratevisualization is not important. Also, there are otherkinds of applications that require combinations oflinear and cartographic or x,y,z data for analyticalpurposes (e.g., linking of linear and area data, suchas wetlands; linking of linear and x,y,z data for

vehicle navigation). In any case, it is possible toenforce constraints on linear referencing systemdesign so that linear locations will have accuraciesthat are compatible with any selected map scale.Anchor section lengths and the accuracies of on-the-ground distance measurement technologiescombine to set an upper bound on the accuraciesof linear locations. The design solution turns thisrelationship around and transforms the accuraciesof linear locations (specified according to userrequirements) into specifications for anchorsection distances and measurement procedures.

Question 5: Why does a traversal have to be madeup of whole links? Why can't a traversal cover part ofa link?

Answer: The notion of traversals being made upof whole links arose from the Milwaukee workshop.Excerpts, transcribed from tape recordings of theworkshop, include the following: “traversal is orderedset of whole links” and “traversals begin and end atnodes.” The definition of traversal was drawn fromthese notes and others that were taken at theworkshop. In my cover memo to workshopparticipants, concerning the first-draft report, I askedfor feedback on this issue. The memo placed the issueunder “points of contention and open questions.” Thequestion was put as “Should traversals be allowed tostart/stop in mid-link?” I received explicit feedbackon this question from three participants. The first said“No” and gave a number of reasons why. The secondsaid “Yes, but not a strong preferenceB.” The thirdsaid “We need to define a 'start' and a 'stop' on a link.”Based upon this response, I made no change. All thereviewers that responded to the first-draft report weregiven the opportunity to respond to a few questions Ihad before preparation of the second-draft report.

I personally do not feel strongly about themodeling question at the heart of this issue.Traversals go from someplace to someplace and“someplace” is usually represented in a network as anode. But if we let traversals start/stop in mid-link,the model is more flexible. I think that this centralissue should perhaps be debated further, but themodel, as it now stands, best represents thesentiments of the Milwaukee workshop participantsas well as I could determine those sentiments.

Question 6: Would you please give a real-worldexample of the link/anchor section ambiguity problemand the need for the association between links and

16

anchor sections in the data model. When would ananchor section form loops (particularly in light of theprevious discussion on anchor section design)?

Answer: My original thinking on the link/ anchorsection ambiguity problem was that it would not arisevery often in real situations. Since then, I have cometo realize that it is much more prevalent. In fact, itoccurs almost all the time. There is ambiguity anytime there is more than one sequence of anchorsections between the two nodes. This same ambiguity,and the same means for resolution, were discoveredearlier by David Fletcher and others on the GIS-TPooled Fund Study when the NCHRP model wasbeing prototyped in the Linear Referencing Engine.

NOTE: Here “sequence of anchor sections”sounds like “path,” but I am using “sequence ofanchor sections” to keep from implying that the lineardatum is a network. Anchor sections can share anchorpoints, but the linear datum does not have to beconnected in the way that a network is.

If I say merely that for link 10, its “from” node ison anchor section 5 at offset 0.54 and its “to” node ison anchor section 5 at offset 1.32, this does not meanthat link 10 is entirely on anchor section 5. The linkcould lie on any sequence of anchor sections from the“from” node to the “to” node. Each of the possiblealternative sequences begins and ends on anchorsection 5. There are two solutions to this problem.One of them is enforcement of a rule that restrictslinks to lie on one and only one anchor section. I thinkthis is too restrictive. There are applications, such asfreight, that might use networks with links that spananchor points. The other solution to the problem is torequire a link-to-anchor section association, so thatthe anchor section(s) on which the link lies areexplicitly stated. This leaves the model flexible andsupporting as many applications as possible, whichwas one of the original goals of the Milwaukeeworkshop participants. This is the solution originallyconceived by the GIS-T Pooled Fund Study.

It is also possible for a single anchor section toform a loop. There is no rule preventing the “from”anchor point and the “to” anchor point of a givenanchor section from being the same. Circle drives canbe modeled in this way. However, the direction(clockwise or counter-clockwise) around the loopmust be specified. This is analogous to the cul-de-sacaddressing problem identified by Sutton and Bespalko(1995). The solution is the same. Either we model itdirectly, or we agree on a standard.

Question 7: The pathologies addressed by Suttonand Bespalko (1995) are related to implementation.They indicate that discontinuous traversals areproblematic and require a set of rules for coding. Forexample, should they be referenced as continuous orshould traversal measures be re-initiated at eachbreak?

Answer: There is a decision to be made atimplementation time, as you point out in yourcomment below. Traversals do not have to becontinuous, but if they are not, we must decidewhether or not to reference them as if they werecontinuous.

Question 7 continuation: So if you have atraversal reference point A that is at offset oA onanchor section 1 from anchor point 1 and traversalreference point B that is at offset oB on anchorsection 5 from anchor point 32, how do you know ifthere are continuous traversal segments between thesetwo traversal reference points or not? You wouldhave to identify the links that make up the traversals,and using the nodes for the links determine if there isa connected path between the traversal referencepoints or not.

Answer: Yes, that is exactly how I would find outif a traversal was continuous between two traversalreference points.

Question 7 continuation: The other part of thisquestion is what measure do I give to traversalreference point B (which is not oB since this is theoffset along the anchor section and not along thetraversal) when the traversal is discontinuous. Do Ireference it as zero to indicate the beginning of a newsection in the traversal or as a positive offset from the“true” beginning of the traversal even though therewill be measured pieces that are not part of thetraversal? This is an implementation question and canonly be addressed in the context of the software andapplications. (I cannot really think of a situationwhere discontinuous route measurement is an issue.For example, if I build snow plow routes, I canindicate blade-up/blade-down sections along thatroute and calculate total plowed miles by summingthe lengths of the blade-down condition. Or, fortransit, we can have in-service/out-of-serviceconditions along the traversal and calculate totalmiles in service. In other words, we reference events

17

to traversals or to the linear datum and work throughthe logical transformations desired.)

Answer: I wholeheartedly agree that this is notreally an issue. We just have to decide how toreference noncontinuous traversals. In one possibledatabase implementation, all locations of interest(e.g., events, traversal reference points, nodes) wouldbe stored as offsets along anchor sections. Querieswould invoke transformation routines that wouldgenerate appropriate traversal offsets, in whateverlinear referencing method is called for, on the fly.Inverse transformations would determine anchorsection offsets for data, collected by whatever linearreferencing method, coming in from the field.

Question 8: The overall data model is designed tofacilitate data integration over multiple cartographicdatabases and for multiple network representationswith presumably many linear referencing methods. Do you have an estimate of how many DOTs actuallymaintain multiple cartographic databases and multiplenetwork representations?

Answer: 5 or 6 years ago, during the initial surveystage of the NCHRP work, a number of agencies wereusing different maps at different scales to build theirGIS spatial databases. Of course, this violates somebasic rules of cartography. They were doing this for atleast two reasons: (1) this mix of maps was all thatwas available and (2) the products from vendors werebased upon data models that allowed only onecartographic representation. Therefore, the scales hadto be mixed.

I do not have comprehensive current informationon what the agencies are doing with multiple mapsand multiple networks today. I suspect that many havedigital maps (if not spatial databases) at differentscales (even though they might not be trying toactively maintain all of them). I also suspect that theyhave tremendous difficulty relating their linearlyreferenced data to more than one network and morethan one cartographic representation without havingmultiple copies of their linearly referenced data.Software in place today just does not support thiskind of multiplicity.

Perhaps we should view the NCHRP model as away of building many integratable databases insteadof one great big integrated database. In this way, itsupports data sharing, not only within a singleorganization, but also across organizationalboundaries. If we all had the same linear datum, the

sharing could be not only horizontal but also vertical.The metropolitan planning organization (MPO) couldgive its linearly referenced data to the DOT and viceversa. The DOT could analyze the MPO’s data,integrate it with the DOT’s data, and display theresults, using the DOT’s linear referencing methods,networks, and cartographic representations. The MPOcould analyze the DOT’s data, integrate it with theMPO’s data, and display the results, using the MPO’slinear referencing methods, networks, andcartographic representations. This could work in thesame way that the DOT currently gets the MPO’s two-dimensional cartographic representation of streets instate plane coordinates and transforms it intoUniversal Transverse Mercator (UTM) coordinates tomatch those of the DOT’s cartographic representation.They can do this because there is a common geodeticdatum for two-dimensional location referencing.

Question 9: How is the linear datum similar to anetwork? How is it different? Can the linear datum beused as a network?

Answer: In some ways, the linear datum is similarto a network. However, there are importantdifferences. The linear datum is not fully connected inthe way a network is. For example, anchor sectionscan pass through intersections without encounteringan anchor point. It might be possible, but it isprobably highly unusual, for a link to pass through anintersection without encountering a node (the node, ofcourse, breaks the link at the intersection). The reasonthat anchor sections can behave this way is that theyhave nothing to do with routing, pathfinding, turns,stops, impedances, or how to get from here to there.Their sole purpose is to represent transportationfacilities in such a way that unique locations can beestablished for things of interest. Nodes representintersections and termini for navigation through anetwork. Anchor points do not. Anchor pointsrepresent appropriate places for endpoints of anchorsections for the purpose of location referencing. Manytimes, an anchor point and a node will have the samelocation. But other times they will not. The onlyplaces where they are required to have the samelocation are at odd-valence intersections and termini.As an example, it might be necessary to place ananchor point (but not a node) along a long stretch ofroadway to create two anchor sections where there isonly one link. This can happen because of accuracyconsiderations in the design of the linear referencingsystem.

18

The only reason that anchor sections share anchorpoints is to reduce the number of anchor points thathave to be managed. There is no functional reasonbeyond simplification of the linear datum—but that isa pretty good reason. It is not necessary to givemultiple anchor point identifiers to a single real-worldfeature just because it is an anchor point for morethan one anchor section. I suppose it is possible togenerate a number of link/node subnetworks from theanchor points and anchor sections of the linear datum,but I do not think such subnetworks would be veryuseful for the kinds of things we need to do withnetworks. The optimum configuration of the lineardatum, designed for location referencing, and theoptimum configuration of a corresponding network,designed for wayfinding, are not the same. I thinkthat, even though the datum is similar to a network insome ways, it should not be thought of as a network.They are really different beasts.

Question 10: Anchor points have a descriptionassociated with them to help locate them in the field.Anchor sections have no description other than thetwo anchor points at their ends, yet their real-worldlengths are also recoverable in the field. How can youdetermine the length of an anchor section if you arelocated at one anchor point and there are multiplepaths to the other anchor point? It seems to me youneed some identifier for the anchor section as well.

Answer: We certainly need identifiers for anchorsections. If these are neutral identifiers (as I think theyshould be), they might not, unto themselves, give usenough information to locate the anchor section in thefield. However, the identifiers will be associated withwhatever names various authorities assign toroadways (perhaps multiple names). With theassociated names, we can find them in the field. If weassociate the anchor sections with cartographicrepresentations, we can also make a map and carrythat into the field.

Here is a related issue. Are the names (not theidentifiers) we assign to roadways different from thenames we assign to traversals? I think they are verysimilar, if not the same. “Highway 51” and “MainStreet” are names for roadways. Are not these closeto the names we would assign to traversals? Maybefor traversals we would add something on direction,like “Highway 51 North.”

Question 11: Why is it that cartographicrepresentations can consist of disjoint groups of lines?

Answer: My recollection of the intent of theMilwaukee workshop participants was to enablepartial two- or three-dimensional mapping. That is,we can still have a linear referencing system eventhough we might not have a map for all of it (or evenpart of it for that matterCwe can have a linearreferencing system without having any map of it atall).

Question 12: Why do you exclude chains from thenetwork component of your data model? Is it becauseyou want to use links and nodes to describe a purelytopological object, while chains mix topology andgeometry?

Answer: Yes, chains are excluded from networksfor that purpose. Chains are included as a possiblekind of line making up a cartographic representation.This addresses a problem that some folks have beenstruggling with for a few years. These people are theones trying to link transportation planning models toGIS databases and software. The networks in theplanning models and the spatial databases in the GISshave nodes in different places. Network nodes existfor analytical purposes. GIS spatial database nodes(at the ends of chains) often exist because of the wayin which the data were captured off a hardcopy map.If we had a linear datum, we could link both theplanning network and the GIS spatial database(cartographic representation) to it. Then it would notmatter if the nodes used in the network and the nodesused in the GIS spatial database were the same nodes.Network analysis would be done in the network andthe results would be displayed in the GIS spatialdatabase (cartographic representation). It is very truethat we would still need to go to the effort of linkingthe network and the cartographic representation to thelinear datum. But everyone would have the samelinear datum. So, the next time we wanted to includesome other (or somebody else's) cartographicrepresentation or network, it would already be linkedto the linear datum, or, at worst, if it was not alreadylinked to the linear datum, we would only have to linkthat object to the linear datum instead of to everycartographic representation and network we alreadyhad.

Question 13: Based on your definitions,traversals, point events, and linear events, are all builtupon links. Does this mean that you cannot locate any

19

linearly referenced events without first building alink/node network?

Answer: No, it does not mean that. As discussedabove, if I were implementing a database, I wouldstore locations of things of interest as offsets alonganchor sections. Therefore, we can know theirlocations without having a network. However, if wewant to go further and do spatial analysis, evensimple things, like finding the distance between twoevents on anchor sections that cannot be connectedthrough the linear datum (because the linear datumdoes not have to be connected), then we need anetwork that is appropriately connected. Also, thelocations of new events, coming in from the field, willbe referenced by some method (e.g., county-route-milepoint). We need a network to transform thatmethod-based reference into a linear datum-basedreference. But if we have a method for referencing,then we automatically have a network.

BIBLIOGRAPHY

Brace, K. and B. Peterson, “Cook County, IllinoisTIGER/Line Conflation and Update Project,”Proceedings, AASHTO Symposium on GeographicInformation Systems in Transportation, Albuquerque,NM (1994).

Briggs, D.W. and B.V. Chatfield, "Integrated High-way Information Systems," NCHRP Report 133.TRB, Washington, DC (1987).Brown, J.N., A.L. Rao, and J. Baran, “Automated GISConflation: Coverage Update Problems andSolutions,” Proceedings, AASHTO Symposium onGeographic Information Systems in Transportation,Sparks, NV (1995).

Cihon, R., Geographic Information Systems ResourceGuide, Washington State Department ofTransportation, Olympia, WA (1996).

Clark, J. and L. Bain, “Integrating a TransportationModel Network into Enhanced TIGER/Line,”Proceedings, AASHTO Symposium on GeographicInformation Systems in Transportation, Albuquerque,NM (1994).

Deighton, R.A. and D.G. Blake, “Improvements toUtah's Location Referencing System to Allow DataIntegration,” presented at the Transportation Research

Board 3rd International Conference on PavementManagement, San Antonio, TX (1993).

Dueker, K.J., “Geographic Information Systems andComputer-Aided Mapping,” Journal of the AmericanPlanning Association, Vol. 53, No. 3 (1987).

Dueker, K.J. and J.A. Butler, “GIS-T Enterprise DataModel with Suggested Implementation Choices,”Center for Urban Studies, School of Urban and PublicAffairs, Portland State University, Portland, OR(1997).

Dueker, K.J. and R. Vrana, “Dynamic SegmentationRevisited: A Milepoint Linear Data Model,” Journalof the Urban and Regional Information SystemsAssociation, Vol. 4, No. 2 (Fall 1992).

Federal Highway Administration, Highway Perform-ance Monitoring System Field Manual, Office ofHighway Information Management, FHWA OrderM5600.1B (1993).

Fletcher, D.R., “Modelling GIS TransportationNetworks,” Proceedings Vol. II, Urban and RegionalInformation Systems Association, 25th AnnualConference, Fort Lauderdale, FL (1987).

Fletcher, D.R., GIS-T Pooled Fund Study Phase BSummary Report, Alliance for TransportationResearch, Albuquerque, NM (1995).Fletcher, D.R., J. Espinoza, R.D. Mackoy, S. Gordon,B. Spear, and A.P. Vonderohe, “The Case for aUnified Linear Referencing System,” Proceedings,Workshop on Enterprise Location ReferencingSystems: Policies, Procedures and Standards forImplementation, Salt Lake City, UT (1996).

Fohl, P., K.M. Curtin, M.F. Goodchild, and R.L.Church, “A Non-Planar, Lane-Based Navigable DataModel for ITS,” National Center for GeographicInformation and Analysis, University of California,Santa Barbara, CA (1996).

Hickman, C., “Feature-Based Data Models and LinearReferencing Systems: Aids to Avoid ExcessiveSegmentation of Network Links,” Proceedings,AASHTO Symposium on Geographic InformationSystems in Transportation, Sparks, NV (1995).

20

Mapping Science Committee, Toward a CoordinatedSpatial Data Infrastructure for the Nation, NationalAcademy Press, Washington, DC (1993)

Michigan Department of Transportation, 1984Reference System Report, Database Task Force,Reference System Review, Lansing, MI (1984).

National Cooperative Highway Research Program,"Highway Location Reference Methods," Synthesis ofHighway Practice 21, TRB, National ResearchCouncil, Washington, DC (1974).

Nyerges, T.L., “Locational Referencing and HighwaySegmentation in a Geographic Information System,”ITE Journal (March 1990).

Nyerges, T.L. and K.J. Dueker, GeographicInformation Systems in Transportation, Office ofPlanning HPN-22, Federal Highway Administration,U.S. Department of Transportation, Washington, DC(1988).

Peterman, V., “Conflation: Merging Spatial DataSets,” Proceedings, AASHTO Symposium onGeographic Information Systems in Transportation,Albuquerque, NM (1994).

Ries, T., “Design Requirements for Location as aFoundation for Transportation Information Systems,”Proceedings, AASHTO Symposium on GeographicInformation Systems in Transportation, Portland, OR(1993).

Ries, T., “Integrating Governments for TransportationPurposes Using a Geospatial Framework,”Proceedings, AASHTO Symposium on GeographicInformation Systems in Transportation, Sparks, NV(1995).

Rowell, R., “Theory and Practice: Linear Referencingat the Idaho Transportation Department,”Proceedings, AASHTO Symposium on GeographicInformation Systems in Transportation,” Kansas City,MO (1996).

Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, andW. Lorensen, Object-Oriented Modeling and Design,Prentice Hall, Englewood Cliffs, NJ (1991).

Scarponcini, P., Location Data Modeling Effort FinalReport, prepared for Minnesota Department of Trans-portation, Graphic Data Systems Corporation (1994).

Scarponcini, P., “A Method for Determining aStandard Linear Referencing Scheme,” Proceedings,AASHTO Symposium on Geographic InformationSystems in Transportation, Sparks, NV (1995).

Siegel, D., “A Non-Traditional Solution toConflation,” Proceedings, AASHTO Symposium onGeographic Information Systems in Transportation,Sparks, NV (1995).

Siegel, D., C. Goodwin, and S. Gordon, ITS DatumPrototype Final Design Report Task C: Spatial DataInteroperability Protocol for ITS Project, FederalHighway Administration, IVHS Research Division,McLean, VA (1996).

Sutton, J., and S. Bespalko, Network Pathologies:Phase 1 Report, Sandia National LaboratoriesTransportation Systems Analysis GIS Project,Document No. AH-2266, prepared by GIS/Trans, Ltd.(1995).

United States Geological Survey (USGS), SpatialData Transfer Standard: Part 1 LogicalSpecifications, Reston, VA (1992).

Vonderohe, A.P., L. Travis, R.L. Smith, and V. Tsai,"Adaptation of Geographic Information Systems forTransportation," NCHRP Report 359, TRB, NationalResearch Council, Washington, DC (1993).

Vonderohe, A.P., C.L. Chou, F. Sun, and T. Adams,“Results of a Workshop on a Generic Data Model forLinear Referencing Systems,” Proceedings,AASHTO Symposium on Geographic InformationSystems in Transportation, Sparks, NV (1995).

21

Vonderohe, A.P. and T.D. Hepworth, "A Meth-odology for Design of a Linear Referencing Systemfor Surface Transportation, Final Report," ProjectAT-4567, Sandia National Laboratories (1996).

Wisconsin Department of Transportation, LocationControl Management Manual, Madison, WI (1996).

22

ACKNOWLEDGMENTS

The commitment and effort of the workshop participants is gratefully acknowledged. This report is a result oftheir work. The participants and their affiliations at the time of the workshop were:

Participant, Affiliation

Teresa Adams, University of WisconsinCMadisonHillary Armstrong, Sandia National LaboratoryMark Bradford, Federal Highway AdministrationJim Carroll, Michigan DOTRichard Church, Univ. of CaliforniaCSanta BarbaraChih-Lin Chou, University of WisconsinCMadisonRon Cihon, Washington DOTDon Diget, Michigan DOTCharles Dingman, United States Bureau of the CensusKen Dueker, Portland State UniversityJoe Ferreira, Massachusetts Institute of TechnologyDavid Fletcher, GeoDigm Consultants, Inc.Cecil Goodwin, University of TennesseeStephen Gordon, Oak Ridge National LaboratoryEdward Granzow, Urban Analysis GroupRobert Harris, GIS TransCharlie Hickman, United States Geological SurveyDale Honeycutt, ESRIWen-Jing Huang, University of WisconsinCMadisonPeggi Knight, Iowa DOTRoy Larson, Minneapolis/St. Paul Metro Council

Simon Lewis, GIS TransFrank Lockfeld, Center for Urban AnalysisDavid Loukes, GeoPlanBill McCall, Iowa State UniversityDaniel McHugh, MTA New York City TransitAlisoun Moore, Maryland State Highway AdministrationTim Nyerges (Facilitator) University of WashingtonPaula Okunieff, Viggen CorporationKen Opiela, Transportation Research BoardCNCHRPTom Ries, Wisconsin DOTJay Sandhu, ESRIBill Schuman, IntergraphSusan Scott, SEI TechnologyRobert Smith, University of WisconsinCMadisonBruce Spear, U.S. Department of TransportationTodd Stellhorn, ESRIJung-Gon Sung, University of WisconsinCMadisonJames Tucker, GDS CorporationAlan Vonderohe (PI), University of WisconsinCMadisonKirk Weaver, New Jersey DOTLynn Williams, Intergraph