The UNETRANS process has developed a draft data model for the transportation industry. This presentation describes how the model can be implementation to support roadway asset management. The implementation incorporates components from Esri ArcGIS software and highways by exor software. It is intended to demonstrate how the Esri transportation model can be used to support real-world road networks, linear referencing systems, and asset databases. Implementation issues and lessons learned are also discussed.
UNETRANS is an acronym both for a generic Esri-centric data model intended to provide framework for Esri users to develop transportation-specific applications using Geodatabase and for the consortium of academics, Esri software users, and business partners formed to guide the development of the model.
The impetus to develop the UNETRANS model came from the adoption by Esri of a new object architecture based on the Microsoft Component Object Model (COM) platform. This held out the promise of all the benefits of object oriented computer programming to the users of Esri software, especially the many users and business partners that use Esri's generic GIS toolkit approach to develop custom solutions. In the object-oriented future these custom solutions would be easier to develop, more robust, and consist of reusable components, like all other object-oriented applications.
Adopting object-oriented analysis and design techniques was an obvious corollary to the object-oriented technology. Esri developers and developers of applications based on Esri software began to use formal methodologies to model and document their programs. They adopted the Unified Modeling Language (UML) developed by Booch, Grady, Jacobson, and Rumbaugh, (Booch et al 1998), which became part of the software documentation. Even Esri advertising material now includes poster-sized, full-color, high level, UML object diagrams of ArcGIS.
Object modeling is the analytical process of describing characteristics of the world that concern a problem. Doing this is not new, but it is traditionally the obscure domain of an incomprehensible few. Object-oriented analysis and design methodologies offer efficient and clear ways to model the world of the software user in a way that is useful to the software developer and that both user and developer can understand. The introduction of ArcGIS resulted in the widespread application of object modeling to GIS applications.
Esri software traditionally and in its new, object-oriented form provides tools to manage low level spatial feature types that can be used to represent a variety of real-world features. The same polyline can be used to represent a road or a pipeline, or a coastline. Real world meaning is associated with the core features in the form of user-defined attributes. The road gets a number of lanes, the pipe gets a diameter, and the coastline gets a field to indicate level of pollution. Custom applications can be written that enable users to interact with the attributes and the features, but these are separate from the basic GIS software, for which the polyline remains a polyline. The great promise of the object-oriented architecture is that behavior could be built into the database, so that the GIS application can recognize the difference between a road feature and a pipe feature and not allow users to append one to the other.
One particularly well organized group of Esri software users in the field of water and wastewater management recognized the potential benefits of carrying out a collective data modeling exercise that addressed their common requirements. Even though some of the participants in this effort compete with each other in the consulting and application development markets, there was a clear benefit to all in incorporating core objects that they all need at the core software level. The worse alternative was that they each develop a version of these objects. This group set an example that was followed by users in other sectors.
The transportation sector group with the acronym UNETRANS was launched officially at the 2000 Esri User Conference, after internal discussions with Esri and the recruitment by Esri of academics from UC Santa Barbara to lead the effort.
The objective of the UNETRANS project is to develop objects that are useful within transportation applications. This is a necessarily broad objective because GIS software is used for a wide variety of transportation applications and the object model should support all of them. The consortium dealt with the potential problem of unwieldiness in several ways. One was to focus on developing only essential object, not every object that might be needed for every application. Another was to defer consideration of all but the most common transportation applications. This illustrates an important benefit of the modular object modeling approach. As long as a versatile high level framework is in place, not have to address all objects in the model have to be defined in detail at the same time. Finally, the model is conceived as a series of packages that address different aspects of the transportation sector (Curtin et al 2001).
This paper and several of these packages address one common requirement within the transportation infrastructure management sector: a network model that can be used as a framework for storing, analyzing, and displaying records that represent assets or events along a road network. ArcInfo has long provided generic feature types and functions that can be used to model a wide variety of networks. Many highway agencies have used it to develop GIS applications to analyze and display spatially data managed within other agency databases. Network Manager, Asset Manager, and Spatial Data Manager, the core modules of the Highways by Exor suite of highway information management products provide this functionality in a Commercial off the shelf (COTS) product. This incorporates both the network data model and the spatial data integration, using Esri technology to manage the spatial data.
Exor is developing an ArcGIS-based application to replace the current ArcView 3.2 Spatial Data Manager client. This project provides an ideal framework to review the value of the UNETRANS object model in implementing real-world transportation infrastructure management applications.
The core problem addressed by Network Manager, Asset Manager, and Spatial Data Manager is to provide a database, including data management and query tools, that usefully represents the real world as it is seen by highway agencies. This world revolves around the highway network. All records either reference part of the network or something that is located along the network. The database has to support specific activities that these agencies carry out, and be updated by and document these activities. Three interrelated problems must be addressed to accomplish this:
- Linear location referencing
- Managing historical data
- Integrating network and geometric data
The first problem is how to efficiently relate every record in the system to the correct network elements. Different departments within large highway agencies have different views of the road network. Those responsible for system-wide maintenance typically define traversals, or routes, across sections of the network and define locations using measures along these sections, starting from the beginning of the section or a jurisdictional boundary that makes sense to them, like a county boundary. Field crews typically use offsets along these same sections from landmarks along the road. Those who deal with public inquiries use street addresses. Often state police agencies have another system for locating accidents along state roads.
These different linear referencing methods make sense for their users, so the system has to support them for data entry and for queries. But it is also important to manage data integrity between all the data in the system. If one system is used to record an accident at a location and another to identify a stretch of low friction pavement in the same place it is important that the enterprise system relates them to the same network location within the database.
The heart of the Highways by Exor suite is a network data model and a set of tools to edit the network and various location referencing methods that are used to locate assets or events along the network, and to make enable users or other systems to query any data in the system using any of these methods. This data model and functionality is provided by Network Manager.
The Highways data model can be reduced to three high-level object classes:
- Network Elements
- Network Placements
- Assets
Network elements are the basic elements of the network, but users can define different types of element. Most users define network sections that are stretches of roadway between intersections. In the NCHRP 20-27 model these are anchor sections, defined simply as network sections of known length between anchor points (Vanderhohe et al 1997). In the UNETRANS model they are defined along TransportEdges in the Reference Network Package.
Another common network type is a group of anchor sections that make up groups of anchor section pieces (e.g. a road network, a rail network, intersections, inspection route, Admin Area, or even a construction project). A third type is measurement extents (Linear Referencing Methods). These correspond to Esri-Routes in the Location Referencing Package of the UNETRANS model.
The ability to subtype network elements like this provides tremendous flexibility. Network elements can have a parent-child relationship. So users can define as many measurement extents (Esri-Routes) as they like on their anchor sections.
Placements are defined locations along network sections. The can be points, referenced with only one measure, or lines, referenced with two measures. They correspond to Point Events and Line Events in the Location Referencing Package of the UNETRANS model. Highways Assets are any records in the system that have locations at placements. They correspond to Assets, Activities, and Events in the UNETRANS model.
Managing data integrity over time is even harder and more important than managing data using several different linear referencing methods. Agencies can, and some do, reduce the number of linear referencing methods by forcing all their departments to use one central one, but none can prevent their networks from changing over time. The network changes in different ways: new road segments are added, existing ones are lengthened or shortened as a result of reconstruction, and roads are added to or removed from the network an agency is responsible for political reasons.
Highway agencies face the challenge of keeping track of changes to their road network, continually updating databases of asset or event information, and keeping these all synchronized. The only way to do it is to manage a central network database and ensure that all other databases are synchronized with this central database. That is what Highways does. All changes to network elements or placements are managed by end-dating the record and, if appropriate, creating a new one with a new date.
Managing historical data presents business logic questions as well as technical ones. When a bypass is built, for example, it may be appropriate to associate historical traffic count data with the new road, because this represents use of the route, but it may not be appropriate to associate historical accident data, because this represents safety issues along the old roadway. Highways enables users to define these rules, but the software cannot make the business decisions.
Spatial data, the shape of the network elements, are at the forefront of our minds in the GIS world, and at the heart of the UNETRANS model. The linear referencing data model described above can be used without any geometric data at all, and is by surprisingly many highway agencies. Often GIS is used to manage a parallel network database, and records from each are synchronized from time to time to support map-based queries and reports.
Highways by Exor, like applications that will be developed based on the UNETRANS model, integrates spatial data into the core network data model. At the theoretical level the network element is independent of the shape, or cartographic representation, as specified in the NCHRP 20-27 (3) model. In practice, one base map is used to edit the network elements and interact with them most of the time. Other cartographic representations are later associated with the network elements for specific purposes (such as strip maps).
Shapes are not represented in the UNETRANS model because they are already part of the ArcGIS data model. At the lowest level shapes within Highways are based also based on Esri or Oracle Spatial feature types. There is a one to one correspondence between line features and network elements. The feature is end-dated and retired whenever it is edited. Spatial data are used in two ways within Highways. One is to provide a map display either for a user interface or for a report. The other is to relate data with two-dimensional, coordinate location attributes to the one-dimensional, network data model. This is useful both for data entry (to snap to the network accident records or vehicle locations that are reported with coordinate locations) and for analysis (such as buffering).
The theory of managing network data models, expounded in voluminous literature, has often led industry practice (Vanderhohe et al 1997, Duecker and Butler 2000, Adams et al 2000). All highway agencies, certainly all state highway agencies in the USA, have working network databases that they use on a day-to-day basis. The majority of these are defined and maintained in tabular form, often in unnormalized desktop or mainframe databases. Traversals or routes are defined to correspond to named or numbered routes that the agency is responsible for. A record for each asset or event along the route is maintained in a table with a fixed number of attribute fields. The table is edited by hand to reflect changes to the real world road system. . Different agencies have different approaches to managing this network database. Few are able to maintain a record of historical changes, and few have any tools to manage data integrity, and many agencies have more than one such database.
This has led to a profusion of network modeling efforts on the one hand, spearheaded by the academic community, and a large number of custom GIS applications on the other, developed or commissioned by highway agencies. The objective of both sets of efforts is to improve on the traditional tabular network database by applying a more sophisticated network data model that incorporates spatial elements. The academics have striven to develop useful generic models; the agencies have striven to encapsulate existing linear referencing business rules in the new GIS databases and applications.
A highway agency typically develops a GIS network database that is calibrated to match the business rules of one or more of its tabular networks. This enables the tables to be jointed to the GIS feature table, and for GIS tools to be used to display or analyze attributes from these tables. Where the GIS network is calibrated to correspond to more than one of the tabular network databases it can act as an integrating tool to combine attribute data from different corporate network models. Where GIS is used this way it inevitably exposes discrepancies between them. The network features in ArcInfo (Arcs, Nodes, sections, routes, and events) provide a versatile toolkit to manage a network database that supports several linear referencing methods and ArcInfo is widely used as the foundation for such applications.
The purpose of the GIS applications has typically been to analyze or display data from other enterprise systems. Sometimes data for one of these systems, say HPMS reporting, is incorporated entirely into a GIS database, and managed there, but usually the only roles that the GIS database and applications play in editing corporate business data is as a source of location attributes and to provide quality control tools. Managing the GIS network and the corporate business data tables in parallel requires duplicate effort, because a record must be maintained for each feature in each database, and it does not provide any opportunity to use records in one database table to validate edits made to another. Many practitioners see supporting this kind of cross-referential data integrity as the holy grail of linear referencing practice and theory. It is almost as elusive.
There are several problems facing any effort to develop useful linear referencing database management tools that integrate many corporate databases within a highway agency:
Data management rules and procedures vary between different business units. They are not necessarily compatible. They do not necessarily all use the same highways as their reference framework.
If the GIS network database is based in GIS technology then it is difficult to embed it in whatever database technology is being used, especially if it is a legacy system based on outdated mainframe technology.
If the network database is developed within the database then there are no adequate tools to manage the spatial aspects of the network or to integrate it with other GIS data. (Until recently database technology has not supported spatial data types well enough for this even to be an option).
If a custom network database is developed, either based on GIS technology, or based on database technology, additional data tables and tools are needed to manage the corresponding business data.
ArcGIS in general and UNETRANS model in particular promise a way to overcome these previously insurmountable obstacles by embedding powerful GIS functionality within a database environment and providing industry-specific objects based on a well-known software development paradigm. Highways by Exor has long provided a solution that circumvents the issues by offering a COTS application that addresses them all. On the spatial side it does this by doing with the previous generation of Esri technology what the UNETRANS model promises to make easier with the next.
Before reviewing the commonalities between the UNETRANS data model and the Highways by Exor data model it is worth revisiting the fundamental differences between the data model and the software and examining important differences at the level of the data model. The essential difference between UNETRANS and Highways by Exor is that UNETRANS provides an object model for database and application development. Highways by Exor is a fully developed end-user system that includes GIS applications of the type that UNETRANS is intended to support, as well as a number of applications specific to highway management such as maintenance management and pavement deterioration modeling. It provides a useful framework to review the UNETRANS model because three Highways modules, Network Manager, Asset Manager, and Spatial Data Manager, provide functionality that UNETRANS was designed to support.
There are two important differences between the data model within Highways by Exor and the UNETRANS data model. The first is a consequence of the fact that UNETRANS is predicated on Geodatabase, and Highways is not. There are two types of objects within the UNETRANS model: Features, which derive from the ArcGIS Geometric Network, and Objects, which do not. Features are tied to shapes in the Geodatabase, and therefore cannot exist unless such a shape exists. The classification of the RouteFeature in the Routes and Location Referencing package as a Feature means that objects can only be located along a route that has a shape. In the Highways data model objects can be located along a route object whether or not it has a shape in the database.
Another difference is the classification of things that are located along the network. The UNETRANS model defines Assets, Activities, and Incidents, each of which can be points or lines. At the lowest level in the Highways data model there are simply Placements, which can also be points or lines. Assets in the Highways data model serve a dual role as generic "things" that can be located along the network, whatever their temporal characteristics, and as a template data structure for actual transportation assets, such as signs or guardrails.
Other modules in the Highways by Exor suite do rely on specific asset types with behaviours For example accidents within Accident Manager, street lights within Street Light Manager, and road openings within Streetworks Manager each have specific attributes and behaviors. Both the Maintenance Manager and Streetworks Manager modules use an inspection object that has temporal and spatial attributes and can be used as a linear referencing method for other assets.
The way that the core transportation network is modeled within Highways by Exor and within the UNETRANS data model is very similar. This is not surprising considering the close involvement of Exor in the UNETRANS consortium.
The NCHRP 20-27 data model provides a convenient framework to compare commonalities between the Highways by Exor and UNETRANS data models, and therefore the UNETRANS objects that Exor is using for its ArcGIS client. Equivalent objects are listed in the table below using their 20-27 designation, their UNETRANS designation, and their Highways by Exor designation.
| NCHRP 20-27 | UNETRANS | Highways |
|---|---|---|
| Anchor point | Anchor point | Anchor point |
| Anchor section | Anchor section | Anchor section |
| Cartographic representation | Defined in the GIS | Defined in the database |
| Event | Activity | Asset |
| Event | Asset | Asset |
| Event | Incident | Asset |
| Linear datum | Reference network | Datum |
| Link | TransportEdge | Network element |
| Network | ReferenceNetwork | Group (of Network Elements) |
| Node | TransportJunction | Node |
| Traversal | RouteFeature | Group (of partial Network Elements) |
| Traversal reference point | Point reference | Placement |
What this table shows is that there are equivalent objects for all the key components of a highway network database in both the UNETRANS model and in Highways by Exor. (It also shows that the NCHRP 20-27 model is providing a uniform language to discuss these elements.) In some instances the low level objects within the highways module are more generic. For example the Group is a concept that enables Network elements, the basic building bricks of the Highways by Exor data model, to be combined in different ways to present different types of object. Examples are linear groups such as RouteFeatures, or non-linear groups such as complex junctions, or simply network extents that correspond to business rules such as inspection routes or maintenance area boundaries.
Applying the UNETRANS model to the next generation of Highways modules presents some difficult choices. The basic choice is whether to rewrite all spatial and non-spatial functionality (e.g. scheduling inspections) using the Geodatabase or to only use ArcGIS for a map-based client application. The map-based client provides such a powerful and intuitive user interface that it is tempting to move all the system functionality to the Geodatabase platform. Unfortunately doing this would prevent the application from working on non-COM server environments. It would also no longer support highways users who have no spatial data.
Supporting an application that is only partially based on the Geodatabase limits the use that can be made of the UNETRANS data model. Parallel objects must be developed for use on the server side (essentially in ArcSDE) and for ArcIMS applications. These other object types are not versioned by ArcIMS, whereas UNETRANS objects must be, so a significant amount of work is required to synchronize the activities of the two.
From this perspective the UNETRANS object model becomes a toolkit for developing a map-based graphical user interface using ArcGIS. Object behaviours remain useful for managing the display of features as they are edited.
The UNETRANS data model is an important step forward for the GIS in Transportation community. With the UNETRANS object model Esri continues to provide a versatile set of core feature types that can be used to model the business rules of highway agencies. It provides a technology foundation on which to develop transportation GIS databases and applications. It also provides a framework for future discussion of transportation objects that it is appropriate to incorporate within COTS GIS software.
ArcGIS, which now underpins both ArcInfo and ArcView will continue to be used by most highway agencies to manage GIS data and to develop GIS applications. These agencies will continue to want applications that incorporate their business rules, and that can be used to display and analyze data from various business databases. This process will become easier with the spread of the common language coined by the NCHRP 20-27 research project to describe linear referencing systems, and with the spread of object oriented analysis and design.
The UNETRANS data model will not only facilitate this process, making it easier to do the things that are being done now. It will also enable more ambitious agencies to develop better integrated applications that manage business and GIS data in the same enterprise database environment. And it will provide Exor to continue provide systems that do this but to improve the GIS aspects of the system using object technology.
Adams, Teresa, Nicholas Koncz, and Alan P. Vonderohe. 2000. "Functional Requirements for a Comprehensive Transportation Location Referencing System" Submitted for publication in the Proceedings of the North American Travel Monitoring Exhibition and Conference, June 2000
Booch, Grady, Ivar Jacobson, James Rumbaugh, Jim Rumbaugh. 1998. The Unified Modeling Language User Guide: The Addison-Wesley Object Technology Series. Boston: Addison-Wesley
Curtin, Kevin, Valerian Noronha, Mike Goodchild, Steve Grisé. 2001. ArcGIS Transportation Data Model (Draft). Esri
Dueker, Kenneth J. and J. Allison Butler. 2000. "A Framework for GIS-T Data Sharing". Submitted to Transportation Research Part C: Emerging Technologies
Vonderohe, A.P., C.L. Chou, F. Sun, and T.M. Adams. 1997. A Generic Data Model for Linear Referencing Systems. Research Results Digest 218. National Cooperative Highway Research Program. Transportation Research Board, Washington, D.C., 1997.