Although there has been some progress made in integrating these data within each domain, identifying and improving the flow of information between them has received less attention. Since activities initiated in one domain affect conditions in the others, defining these flows is crucial to the next generation of planners, traffic managers and transportation service users. For example, construction and maintenance activities influence civilian and military route choices and travel times. Conversely, large-scale military movements disrupt civilian travel and have potentially major effects on the infrastructure. This intertwined interest in the transportation system identifies the need for data integration not only within each sphere of interest but among the spheres as well. Although recent policy statements by the U.S. Departments of Transportation and Defense indicate a desire to share information, significant technical and institutional barriers exist.

Over the past decade, information analysts in all three domains have independently concluded that site and event locations are primary information needs and that location attributes are primary keys in developing information integration strategies. Knowing where components and events are relative to one another is essential for planning and operational decision-making. Additionally, these locations serve as a significant integrating mechanism when used as the basis for the organizing information and designing geographic information systems for transportation (GIS-T). Consequently, while there has been considerable work done in each domain to define location reference methods and standards, no one has attempted to define a unified approach applicable across all three domains.

Recognizing the fair degree of overlap among these independent efforts and the opportunity to establish a single location-control framework encompassing all three domains, representatives from each domain met to explore such an option¹ . Those representatives, along with several invited location experts, conducted a day and a half of technical discussions. The group concluded that a single, comprehensive approach to location control could meet the needs of public sector, civilian and military transportation users. The group also determined that this approach should be led by the federal government and supplemented by state and local transportation efforts.

…the collection of objects which serve as the basis for locating the linear referencing system in the real world. The datum relates the database representation to the real world and provides the domain for transformations among linear referencing systems and among geographic representations. The datum consists of a connected set of anchor sections that have anchor points at their junctions and termini. No (application) attributes are assigned to the datum. (Vonderohe et al. 1995)

Figure 1 illustrates the relationships among the various objects comprising a linear reference system. Domain-specific applications determine actual transportation objects and events labeled as domain locations. Each site or vehicle can be located by various linear reference methods using combinations of field and office procedures, unique to that domain or application. Multiple application dependent topologies (i.e., transport links and nodes) can be defined and referenced to the datum as well. The key innovation offered by the universal datum is that all of the application specific objects are referenced to a single datum. This datum can also be attached to multiple cartographic representations for display purposes.

A unified linear datum encompasses national, statewide and local transportation facilities and controls infrastructure, vehicle and container locations. The significant point is that public sector transportation managers, the ITS community and the military all use the same underlying datum. This common structure will provide for the unambiguous transfer of location-based data both within and among these groups. Of course, not all applications will require every component contained in the datum. The unified approach requires only that there be exactly one anchor section controlling a specific fragment on the transportation system. This section controls all location methods that fall within its linear extent.

The control framework is not a transport systems application network. That is, the datum does not include any transport systems flow topology or application data (e.g., capacity, demand or impedance characteristics). Routes, junctions, intersections, terminals, travel links and other domain-specific objects relate to the datum; they are not parts of it. Control surveying principles, not on-transport logic, guide the procedures for determining the locations and extents of the datum components (Vonderohe and Hepworth 1998).

Several issues impede the progress toward a unified, surface transportation-location strategy. These are a combination of conceptual, semantic, technical and operational factors. True unification will depend on overcoming each of these.

1. There is considerable confusion over the distinctions between field, map and database "location"

concepts. Field data collectors generally view locations as measurements referenced to an arbitrary number of known reference objects. Mapmakers view locations as Cartesian coordinates referenced to some planar origin. Database designers view locations as data-indexing mechanisms. Each camp uses a variety of measurement and coordinate systems. Because of the contextual differences among field, map and data base views, each requires separate objects, and business rules. Field positions, map locations and database addresses are not the same attributes and will not generally have the same coordinate values.² Many transportation agencies attempted to use field locations or map positions as database keys. This strategy was difficult to maintain over time because of the dynamic nature of the field locations (e.g., changes in route designations and changes in mile point values resulting from realignments). A smaller number of agencies were equally unsuccessful in their attempts to use data base keys as field locations.

2. Over the past few years there have been several national efforts aimed at producing a standard

non-proprietary model specification for linear reference (Seigal et. al. 1996; Vonderohe et al. 1995; Fletcher et al.1995). However, at this time there is still a lack of "universal" consensus about these specifications. Indeed, most people in this field still do not understand the concept of an application independent linear datum used only to control the relative locations of linear objects and events.

3. Although the first linear reference software appeared more than 20 years ago, there is still a lack of

technical support (i.e., products and services) of linearly referenced location data. Most software is still ad hoc and idiosyncratic. Most of these proprietary approaches have sacrificed conceptual rigor for application specific performance enhancement. To the best of the authors’ knowledge,only a few commercially available software systems can support the requirements laid out in the cited references.

4. Given the lack of a standard specification and the consequential lack of supporting technology, the final impedance to a unified approach is the lack of operational experience with developing and managing large control frameworks. There is not enough "real-world" experience to convince any but the most risk tolerant to abandon their current efforts and adopt a new strategy.

The case for a unified linear datum starts with the following propositions. These propositions outline the basic technical and institutional architecture for the datum. Table 1 illustrates various control datums used in the United States and serves as the basis for the following propositions:

The following specifications are an incomplete set of requirements for the unified linear datum. These specifications represent the datum users’ expectations.

1. The purpose of the datum is to transform locations between the real-world space and data-world space(s) and to project positions between data spaces.
2. The datum needs to be a consistent, nationwide framework accessible to public and private customers.
3. Multiple public domain and proprietary databases will use the datum.
4. Although the datum itself must be in the public domain, many applications using this framework will be proprietary.
5. The datum needs to be able to control location at multiple levels of resolution (e.g., highway location, roadway location, lane location).
6. The datum needs to be able to control locations determined by many different methods (e.g., route and mile point, route and reference point, control section and offset).
7. Each functional domain has distinctly different accuracy specifications. This is a function of either the smallest objects (i.e., the highest resolution) in the domain(s), the need to discriminate the relative distance between two objects or the precision of the location measurement devices.
8. Navigation and traveler information functions need 3- to 5-meter positional accuracy. The need to discriminate between or resolve the location of individual vehicles determines this requirement.
9. Datum and reference objects need to be identified easily in the field. These objects also need to be fixed, stable and recoverable over long periods of time (decades, if not longer).
10. The unified datum should be domain-content (i.e., application) neutral.

The workshop participants developed a preliminary set of design specifications for the datum guided by the following design principles. A more detailed set of specifications may be obtained from the primary author.

• Field location reference objects need not be the same as datum objects. The same real world feature (e.g., an at-grade intersection) may have a number of roles and be represented in the database by multiple objects (e.g., a node, an anchor point, a traversal reference point).

In order for the unified linear datum to exist, it needs an institutional context. The participants agreed that the overwhelming use of the unified approach will be for ITS applications. As a result, it makes sense that the datum be established and supported by this initiative. The following recommendations are based on that assumption.

Fletcher, D.; T. Henderson and J. Espinoza. 1995.  GIS-T/ISTEA Management Systems Server-Net Prototype Pooled Fund Study Systems Analysis and Preliminary Design; Albuquerque NM.

Seigal, D.; S. Gordon and C. Goodwin. 1996. The ITS Datum Preliminary Data Structure and Content; Oak Ridge, TN.

Vonderohe, A.P.;C.L. Chou, F. Sun and T. Adams. 1995. "Results of a Workshop on a Generic DataModel for Linear Referencing Systems;" In Proceedings, AASHTO Symposium on Geographic Information Systems in Transportation, Sparks, NV.

Vonderohe, A.P. and T. Hepworth. 1997. A Methodology for Design of a Linear Referencing System for Surface Transportation; SAND97-0637; Sandia National Laboratories; Albuquerque, NM.

David Fletcher is an associate director of the ATR Institute at the University of New Mexico. His research interests encompass the breadth of topics constituting transportation informatics, including GIS-T and location referencing.

Juan Espinoza Jr. is a senior member of technical staff at Sandia National Laboratories in Albuquerque, NM. He has been involved for 17 years in many national security related fields such as facility safeguards and security, treaty verification, information system surety, and advanced transportation.

R.D. Mackoy is a senior member of technical staff at Sandia National Laboratories and has been there for 11 years. His specialty is in interfaces to computers, both carbon-based fleshware and hardware.

Stephen Gordon is the manager of the ITS Research Group in the Center for Transportation Analysis, ORNL.

Bruce Spear is director of the Office of Geographic Information Services at the U.S. Department of Transportation, Bureau of Transportation Statistics, in Washington, DC. Prior to this, he was the GIS program manager at the Volpe National Transportation System Center in Cambridge, MA.