Standard Article

You have free access to this content

Data Handling in Intelligent Transportation Systems

  1. John F. Dillenburg,
  2. Peter C. Nelson

Published Online: 15 JAN 2008

DOI: 10.1002/9780470050118.ecse511

Wiley Encyclopedia of Computer Science and Engineering

Wiley Encyclopedia of Computer Science and Engineering

How to Cite

Dillenburg, J. F. and Nelson, P. C. 2008. Data Handling in Intelligent Transportation Systems. Wiley Encyclopedia of Computer Science and Engineering. .

Author Information

  1. University of Illinois at Chicago, Chicago, Illinois

Publication History

  1. Published Online: 15 JAN 2008

1 Introduction

  1. Top of page
  2. Introduction
  3. Major Challenges
  4. Data Handling in ITS
  5. Bibliography

Within the domain of computer science, data handling is the coordinated movement of data within and between computer systems. The format of the data may be changed during these movements, possibly losing information during conversions. The data may also be filtered for privacy, security, or efficiency reasons. For instance, some information transmitted from an accident site may be filtered for privacy purposes before being presented to the general public (e.g., license numbers and names). The motivation for this article is to be an updated reference of the various mechanisms and best practices currently available for handling intelligent transportation systems (ITSs) data. In the sections that follow, data handling within ITS is discussed in detail.

1.1 What are Intelligent Transportation Systems?

Intelligent transportation systems apply computer, communication, and sensor technologies in an effort to improve surface transportation. The application of these technologies within surface transportation typically has been limited (e.g., car electronics and traffic signals). One goal of ITS is to broaden the use of these technologies to integrate more closely travelers, vehicles, and their surrounding infrastructure. Used effectively, ITS helps monitor and manage traffic flow, reduce congestion, provide alternative routes to travelers, enhance productivity, respond to incidents, and save lives, time, and money. Over the past ten years, the public and private sectors have invested billions of dollars in ITS research and development and in initial deployment of the resulting products and services.

Given the potential benefits of ITS, the U.S. Congress specifically supported an ITS program in the Transportation Equity Act for the 21st Century (TEA-21) in 1998. As defined by TEA-21, the ITS program provides for the research, development, and operational testing of ITSs aimed at solving congestion and safety problems, improving operating efficiencies in transit and commercial vehicles, and reducing the environmental impact of growing travel demand. Technologies that were cost effective were deployed nationwide within surface transportation systems as part of TEA-21.

Intelligent transportation systems can be broken down into three general categories: advanced traveler information systems, advanced traffic management systems, and incident management systems.

Advanced Traveler Information Systems (ATISs) deliver data directly to travelers, empowering them to make better choices about alternative routes or modes of transportation. When archived, this historical data provide transportation planners with accurate travel pattern information, optimizing the transportation planning process.

Advanced Traffic Management Systems (ATMSs) employ a variety of relatively inexpensive detectors, cameras, and communication systems to monitor traffic, optimize signal timings on major arterials, and control the flow of traffic.

Incident Management Systems, for their part, provide traffic operators with the tools to allow a quick and efficient response to accidents, hazardous spills, and other emergencies. Redundant communications systems link data collection points, transportation operations centers, and travel information portals into an integrated network that can be operated efficiently and “intelligently.”

Some example ITS applications include on-board navigation systems, crash notification systems, electronic payment systems, roadbed sensors, traffic video/control technologies, weather information services, variable message signs, fleet tracking, and weigh in-motion technologies.

2 Major Challenges

  1. Top of page
  2. Introduction
  3. Major Challenges
  4. Data Handling in ITS
  5. Bibliography

One major challenge in handling ITS data involves managing the broad spectrum of requirements inherent in a transportation system. ITS data must flow from and between a variety of locations and devices such as in-vehicle sensors, police dispatch centers, infrastructure sensors, computers, and databases. Each of these options has different bandwidth, formatting, and security requirements. A “one-solution-fits-all” approach is not appropriate in this type of environment. Fortunately, many standards can be applied in concert with one another to cover all requirements. These standards and how they are used are discussed in the sections that follow.

3 Data Handling in ITS

  1. Top of page
  2. Introduction
  3. Major Challenges
  4. Data Handling in ITS
  5. Bibliography

Data within an ITS originates at various sensors, such as in-pavement inductive loop detectors for measuring the presence of a vehicle, transponders for collecting toll fees, video cameras, and operator input. These data typically are collected and aggregated by a transportation agency for use in managing traffic flow and in detecting and responding to accidents. These data are often archived, and later data-mining techniques are used to detect traffic trends. These data also make their way to information providers for use in radio, television, and Web traffic reports.

The different requirements for ITS data handling depend on the medium used. For instance, the requirements for data handling in communications stress the efficient use of bandwidth and low latency, whereas data handling for data-mining applications require fast lookup capabilities.

3.1 Data Types and Formats

Various types of data are stored and manipulated by an ITS. The types of data are discussed in the sections that follow.

3.1.1 Traffic Statistics

Speed, travel time, volume, and occupancy data or other numeric measurements are used to characterize the flow of vehicles at a specific point or over a specific segment of roadway. These data can be generated from many types of detection systems, such as loop detectors, microwaves, infrared or sonic detectors, video image detection, automatic vehicle identification, license plate matching systems, and wireless phone probes.

3.1.2 Weather/Environmental

Wind speed, wind direction, temperature, humidity, visibility, and precipitation data are collected by weather stations. This information can be used to determine whether road salt is needed because of icing conditions or whether danger exists to large vehicles because of high wind speeds.

3.1.3 Video/Images

Video cameras are mounted high to provide unobstructed views of traffic. Video data are in the form of encoded data streams or still images. Video feeds are used to determine the cause and location of incidents and to determine the overall level of service (congestion).

3.1.4 Incident/Event Reports

Incidents, construction/ maintenance, events, and road conditions are some types of data collected. This information usually is entered manually into the “system” because an automated means of detecting an incident has yet to be developed. The reports provide descriptive information on planned or unplanned occurrences that affect or may affect traffic flow.

3.1.5 Data Attributes

The following attributes are common within ITS data: Accuracy—How precise is the data? Detail—Is the data a direct measurement or an estimated/indirect measurement? Timeliness—How fresh is the data? Availability/Reliability—How dependable is the flow of data? Density—How close together/far apart are the data collection sources? Accessibility—How easy is the data accessed by a data consumer? Confidence—Is the data trustworthy? Coverage—Where is the data collected?

3.2 Standards for Data Handling

Standards provide a mechanism to ensure compatibility among various disparate systems. These standards reduce costs because software and hardware can be developed to make use of a handful of standards rather than of hundreds of proprietary protocols.

The following organizations are involved in the development of ITS standards: the American Association of State Highway and Transportation Officials (AASHTO), American National Standards Institute (ANSI), American Society for Testing & Materials (ASTM), Consumer Electronics Association (CEA), Institute of Electrical and Electronics Engineers (IEEE), Institute of Transportation Engineers (ITE), Society of Automotive Engineers (SAE), National Electrical Manufacturers Association (NEMA), and the National Transportation Communications for ITS Protocol (NTCIP). Note that NTCIP is a joint effort among AASHTO, ITE, and NEMA.

The Federal Geographic Steering Committee (FGSC) provides staff to support the U.S. Department of the Interior to manage and facilitate the National Spatial Data Infrastructure (NSDI) (1).

3.2.1 Data Formats and Communication Protocols

Standards are built off of one another. For instance, ITS standards make use of standards for data formatting and communications, such as Extensible Markup Language (XML), Common Object Request Broker Architecture (CORBA), or Abstract Syntax Notation number One (ASN.1). To better understand ITS standards, these underlying standards will be discussed first. Extensible Markup Language

XML is a standard of the World Wide Web Consortium (W3C) (2). XML is a means of encoding data so that computers can send and receive information. XML allows computers to understand the information content of the data and act on that content (e.g., process the information, display the information to a human, store the information in a database, and issue a command to a field device). Unlike most computer encoding standards (e.g., Basic Encoding Rules, Octet Encoding Rules, Packed Encoding Ruled, Common Data Representation, and Hypertext Markup Language), no single set of encoding rules exists for XML. Instead, XML encoding rules are customized for different applications. Furthermore, XML encoding rules include a mechanism for identifying each element of an XML document or message. See Ref. 3 for an overview of XML use in ITS applications.

The advantages of using XML for ITS data handling are for communications. It has pervasive support among software companies, standards organizations, and government agencies. Also, XML formatted data are often bundled with Web services over Hyper-Text Transmission Protocol (HTTP) via SOAP (4) or XML-RPC (5). This bundling allows the data and associated commands to traverse firewalls more easily. Some may see this process as a disadvantage, however, because it basically is hiding the services from network administrators and granting potentially unsecured access to important functions.

XML format is not well suited for data storage, however, because its hierarchal data structure does not lend itself to easy storage and retrieval from relational databases. However, XML databases, which natively can store, query, and retrieve XML-formatted documents, are now available (6).

A disadvantage to XML-formatted data is that the tags and the textual nature of the documents tend to make them much more verbose. This verbosity, in turn, requires higher bandwidth communication links and more data processing to encode and decode ITS data as compared with CORBA or ASN.1 (7, 8). Common Object Request Broker Architecture

CORBA is an Object Management Group (OMG) standard for communications between computers (9). As part of CORBA, the interface definition language (IDL) provides a platform and computer language-independent specification of the data to be transmitted and the services that are available to a CORBA application. The OMG requires CORBA implementations to make use of the Internet Inter-ORB Protocol (IIOP) for encoding messages over the Internet. This protocol ensures that CORBA implementations from different vendors running on different operating systems can interact with one another. NTCIP has a CORBA-based standard for communications between transportation centers, NTCIP 2305 (10). CORBA inherently is object oriented, which allows for the definition of both data structures and for commands in the form of interfaces.

One advantage to using CORBA are its relatively lower bandwidth requirements as compared with XML-based communications. CORBA has wide industry support, and many open-source implementations are available (11, 12). Because CORBA is based on the IIOP communications standard, the various commercial and open-source implementations can interoperate with one another. CORBA has the advantage, as compared with ASN.1 or XML, in that it describes both the structure of the data to be transmitted and what is to be done with the data. Finally, many counterpart extensions to CORBA handle such things as authentication.

The disadvantages to CORBA are that it requires specialized knowledge to integrate it into ITS data handling systems. Also, because CORBA does not make use of the HTTP protocol, it does not traverse Web firewalls as easily as XML-RPC or SOAP. Abstract Syntax Notation

ASN.1 is a standard of the International Standards Organization (ISO) that defines a formalism for the specification of abstract data types. ASN.1 is a formal notation used for describing data transmission protocols, regardless of language implementation and physical representation of these data, whatever the application, whether complex or very simple. ASN/DATEX is a NTCIP standard (NTCIP 2304). ASN.1 is not a communication or data storage mechanism, but it is a standard for expressing the format of complex data structures in a machine-independent manner. Many encoding rules can encode and decode data via ASN.1 such as the basic encoding rules (BERs), canonical encoding rules (CERs), and distinguished encoding rules (DERs) (13).

ASN.1 has the advantage that it unambiguously defines the structure for ITS data and the various encoding schemes allow for efficient transmission of the data over even lower bandwidth communication systems. Many software libraries are also available that handle the encoding and decoding of ASN.1 data structures (14).

3.2.2 ITS Data Bus

Chartered in late 1995, the Data Bus Committee is developing the concept of a dedicated ITS data bus that may be installed on a vehicle to work in parallel with existing automotive electronics (15). When complete, the data bus will facilitate the addition of ITS electronics devices to vehicles without endangering any of its existing systems.

The ITS data bus will provide an open architecture to permit interoperability that will allow manufacturers, dealers, and vehicle buyers to install a wide range of electronics equipment in vehicles at any time during the vehicle's lifecycle, with little or no expert assistance required. The goal of the Data Bus Committee is to develop SAE recommended practices and standards that define the message formats, message header codes, node IDs, application services and service codes, data definitions, diagnostic connectors, diagnostic services and test mode codes, ITS data bus–vehicle bus gateway services and service codes, network management services/functionality, and other areas as may be needed.

3.2.3 National ITS Architecture

The National ITS Architecture provides a common framework for planning, defining, and integrating intelligent transportation systems (16). It is a mature product that reflects the contributions of a broad cross section of the ITS community: transportation practitioners, systems engineers, system developers, technology specialists, and consultants. The architecture provides high-level definitions of the functions, physical entities, and information flows that are required for ITS. The architecture is meant to be used as a planning tool for state and local governments.

3.2.4 Traffic Management Data Dictionary

The Data Dictionary for Advanced Traveler Information Systems, Society of Automotive Engineers (SAE) standard J2353, provides concise definitions for the data elements used in advanced traveler information systems (ATIS) (17). These definitions provide a bit-by-bit breakdown of each data element using ASN.1. The traffic management data dictionary is meant to be used in conjunction with at least two other standards, one for defining the message sets (e.g., SAE J2354 and SAE J2369) and the other for defining the communication protocol to be used.

3.2.5 TransXML

XML Schemas for the exchanges of Transportation Data (TransXML) is a fledgling standard with the goal to integrate various standards such as LandXML, aecXML, ITS XML, and OpenGIS into a common framework. This project has not had any results yet; see Ref. 18 for more information.

3.2.6 Geography Markup Language

Geography markup language (GML) is an OpenGIS standard based on XML that is used for encoding and storing geographic information, including the geometry and properties of geographic features (19). GML was developed by an international, nonprofit standards organization, the Open GIS Consortium, Inc. GML describes geographic features using a variety of XML elements such as features, coordinate referencing systems, geometry, topology, time, units of measure, and generalized values.

3.2.7 Spatial Data Transfer Standard

The Spatial Data Transfer Standard (SDTS) is a National Institute of Standards (NIST) standard for the exchange of digitized spatial data between computer systems (20). SDTS uses ISO 8211 for its physical file encoding and breaks the file down into modules, each of which is composed of records, which in turn are composed of fields. Thirty-four different types of modules currently are defined by the standard, some of which are specialized for a specific application.

3.2.8 LandXML

LandXML is an industry-developed standard schema for the exchange of data created during land planning, surveying, and civil engineering design processes by different applications software. LandXML was developed by an industry consortium of land developers, universities, and various government agencies. LandXML is used within GIS applications, survey field instruments, civil engineering desktop and computer aided design (CAD)-based applications, instant three-dimensional (3D) viewers, and high-end 3D visualization rendering applications. LandXML has provisions for not only the storage of a feature's geometry, but also for its attributes, such as property owner and survey status. LandXML can be converted readily to GML format.

3.2.9 Scalable Vector Graphics

Scalable vector graphics (SVG) is an XML-based standard for the storage and display of graphics using vector data and graphic primitives. It primarily is used in the design of websites, but also it has application for the display and transfer of vector-based geographic data. It does not, however, have specific provisions for the attributes that are associated with geographic data such as road names and speed limits. Location Referencing Data Model

The location referencing data model is a National Cooperative Highway Research Program (NCHRP) project that defines a location referencing system. Within this system, a location can be defined in various formats such as mile points or addresses. It also provides for the conversion of a location between the various formats and for the definition of a location in one, two, or more dimensions (21). International Standards Organization Technical Committee 211

The International Standards Organization Technical Committee 211 (ISO TC/211) has several geographic standards that are of importance to intelligent transportation systems: Geographic information—Rules for Application Schema; ISO 19123, Geographic information—Schema for coverage geometry and functions; and ISO 19115, Geographic information—Metadata.

3.3 Data Mining and Analysis

Data mining and analysis of transportation data are useful for transportation planning purposes (e.g., transit development, safety analysis, and road design). Data quality especially is important because the sensors involved can malfunction and feed erroneous data into the analysis process (22). For this reason, ITS data typically needs to be filtered carefully to assure data quality. This filtering is accomplished by throwing out inconsistent data. For instance, a speed detector may be showing a constant free flow speed while its upstream and downstream counterparts show much slower speeds during peak usage hours. In this case, the inconsistent detector data would be thrown out and an average of the up and downstream detectors would be used instead.


  1. Top of page
  2. Introduction
  3. Major Challenges
  4. Data Handling in ITS
  5. Bibliography