The Development of A Full-Digital and Networkable

Multi-media based Highway Information System, Phase I

Final Report

Submitted to

Mack-Blackwell Transportation Center

> Principal Investigator: Kelvin C.P. Wang
>
> Co-Principal Investigator: Robert P. Elliott
>
> Research Associate: Xuyang Li

Department of Civil Engineering

University of Arkansas, Fayetteville

July 26, 1999

# Acknowledgments

Support for this project was provided by a grant from the U.S.
Department of Transportation to the Mack-Blackwell Transportation Center
at the University of Arkansas, Fayetteville.

# Project Abstract

This report covers the development of a Multimedia Based Highway
Information System (MMHIS). MMHIS extends the capabilities of current
photo logging facilities. Photographic logging systems used by highway
agencies provide engineers with information in the analysis of traffic
accidents, design improvements, and highway pavement management.
However, there exist limitations for such systems in the areas of
accessibility, search capability of the image library, and
synchronization of the video data with traditional engineering site
data. The analog nature of the video signals also presents difficulties
in integrating the visual information with other types of data. This
report presents the development of a multimedia service that can be
applied in a state highway department environment. This Multimedia-based
Highway Information System (MMHIS) utilizes state-of-the-art
technologies in digital video, high-speed networking, and the video
server. A data-synchronization algorithm was developed to dynamically
display digital video frames along with traditional engineering data
sets that contain information such as as-built data, pavement condition
and performance, traffic safety, geometric features, and other
infrastructure data. Geo-referencing capabilities were also developed
into MMHIS, so that multimedia data is location-referenced in the
databases.

# Report Summary

Visual information is frequently used in highway departments for traffic
engineering and infrastructure management. Another type of information
is tabulated site data organized in traditional engineering databases on
pavement history and layer information, pavement width/type, average
daily traffic (ADT), accident history, signing and marking inventory,
and others. These two types of information (roadway images and
traditional engineering database) can be of daily benefit to the needs
of various divisions in state highway departments.

Highway departments would have much greater access to data if these two
information sources could be combined into one comprehensive database
that could be accessed simultaneously. However, most existing photo
logging systems used by highway departments are analog based and located
at specific location(s) within the department. Traditional engineering
site data are contained separately from the video databases, and
simultaneous multiple accesses to the video data are not possible.
Searching for site data is a cumbersome process.

A few studies have attempted to exploit new technologies to improve the
accessibility and usability of video information collected from the
photo logging process. Wang et al. \[1\] presented general concepts and
design issues for the development of a distributed multimedia based
highway information system (MMHIS) and discussed the economic and
technical feasibility of using digital video and new networking
technologies for such a system. It was concluded in that study that the
latest technology allows such a system to be developed cost-effectively.

The present report summarizes the studies in the areas of high-speed
networking, video server technology, and data synchronization that are
essential for the implementation of an MMHIS. To implement the MMHIS in
an operational environment, a high-performance network and a powerful
video and storage server are necessary. In addition, for simultaneous
and instant access to the MMHIS data, the application of new
technologies such as Asynchronous Transfer Mode (ATM) or FastEthernet,
and Redundant Arrays of Inexpensive Disks (RAID) are needed. A plausible
alternative to building a wide area network may be to install a
high-performance network system in the headquarters of a highway
department and distribute hard copy videodisks to remote district
offices. For example, the maximum capacity of a new kind of CD, the
Digital Versatile Disk (DVD), is 18.8 gigabytes, which can hold 400
lane-miles of video information at MPEG2 quality. This report describes
the working system already developed for the Arkansas Highway and
Transportation Department (AHTD), which has a user intuitive interface.
The report also includes a guide on how to use this system.

We believe that the technologies associated with the implementation of
MMHIS are mature and that the costs of implementation are continuing to
come down. The cost-effectiveness of using the MMHIS is evident not only
in greater office productivity but also in the actual cost savings
resulting from reduced travel for site inspections. Preliminary highway
site inspection normally involves two people and can take as much as two
or more days. If the number of such trips can be reduced through the use
of the MMHIS, a highway department can realize substantial savings in
travel and labor costs in just one year.

As MMHIS is technology-driven, additional features can be built into
MMHIS over time. New features of Geographic Information System and
high-resolution 3-D terrain data will be useful for an integrated
highway management and design. When statewide terrain data in the MMHIS
are updated with Digital Elevation Models (DEM) of sub-meter resolution,
it is possible to conduct preliminary engineering design of cut-and-fill
and planning for new transportation systems.

**Table of Contents**

List of Tables [viii](#list-of-tables)

List of Figures [ix](#list-of-figures)

Introduction [1](#introduction)

History of Photo-logging System and Basic Requirement of MMHIS
[2](#history-of-photo-logging-system-and-basic-requirement-of-mmhis)

Problems with Existing Photo-logging Systems
[2](#problems-with-existing-photo-logging-systems)

Basic Features of MMHIS [2](#basic-features-of-mmhis)

New Technologies of Digital Video and Geo-Referencing
[4](#new-technologies-of-digital-video-and-geo-referencing)

Digital Video for MMHIS [4](#digital-video-for-mmhis)

Data Collection, Compression and Decompression (CODEC)
[4](#data-collection-compression-and-decompression-codec)

Geo-referencing Technologies [5](#geo-referencing-technologies)

3D Database File Structures [6](#d-database-file-structures)

Generating the 3D Map Database [7](#generating-the-3d-map-database)

Picking Operations [10](#picking-operations)

Location Synchronization with Video and Site Data
[11](#location-synchronization-with-video-and-site-data)

Data Synchronization Algorithms and Implementation
[12](#data-synchronization-algorithms-and-implementation)

The Preparation of Video Frame Index
[12](#the-preparation-of-video-frame-index)

The Synchronization of Video and Site Data Display
[14](#the-synchronization-of-video-and-site-data-display)

Database Structures of MMHIS [15](#database-structures-of-mmhis)

The State Registration Table [15](#the-state-registration-table)

The State Master Table [16](#the-state-master-table)

Fixed Data Table [17](#fixed-data-table)

The Data Format Table [18](#the-data-format-table)

The Frame Index Table [19](#the-frame-index-table)

The Turning Movement Information Table
[20](#the-turning-movement-information-table)

The Yearly Registration Table [20](#the-yearly-registration-table)

The Yearly Data Table [20](#the-yearly-data-table)

Functional Dependencies of Databases
[21](#functional-dependencies-of-databases)

Database Indexes [22](#database-indexes)

Network and Hardware Issues in a Production Environment
[24](#network-and-hardware-issues-in-a-production-environment)

MMHIS Network Performance Requirements
[24](#mmhis-network-performance-requirements)

Asynchronous Transfer Mode (ATM) and Gigabit MMHIS
[25](#asynchronous-transfer-mode-atm-and-gigabit-ethernet)

ATM Performance Characteristics [26](#atm-performance-characteristics)

Quality of Service (QOS) [27](#quality-of-service-qos)

Gigabit Local Area Networking for MMHIS
[27](#gigabit-local-area-networking-for-mmhis)

The Video and Storage Server [28](#the-video-and-storage-server)

Issues Related to Multimedia Oriented Network Operating Systems
[28](#issues-related-to-multimedia-oriented-network-operating-systems)

Requirements for the Multimedia Storage Server
[28](#requirements-for-the-multimedia-storage-server)

File System for the Server [30](#file-system-for-the-server)

Disk Arrays for the Server Storage
[31](#disk-arrays-for-the-server-storage)

MMHIS Development [31](#mmhis-development)

The Hardware Structure for the MMHIS
[32](#the-hardware-structure-for-the-mmhis)

Operation of MMHIS [34](#operation-of-mmhis)

Starting up the System [34](#starting-up-the-system)

Starting a New Query [34](#starting-a-new-query)

Opening an Existing Query [35](#opening-an-existing-query)

Running a Query [35](#running-a-query)

Dynamic Graphing [42](#dynamic-graphing)

Using the map [43](#using-the-map)

Building the video frame index [45](#building-the-video-frame-index)

Conclusion [47](#conclusion)

References [48](#references)

# List of Tables

Table 1 -- MMHIS 3D Map Databases [6](#__RefHeading___Toc417708308)

Table 2 -- Index Building Module Input
[12](#__RefHeading___Toc417708309)

Table 3 -- The Structure of State Registration Table
[16](#__RefHeading___Toc417708310)

Table 4 -- The Structure of the State Master Table
[17](#__RefHeading___Toc417708311)

Table 5 -- The structure of fixed data table
[18](#__RefHeading___Toc417708312)

Table 6 -- The Structure of the Data Format Table
[19](#__RefHeading___Toc417708313)

Table 7 -- The Structure for the Frame Index Table
[19](#__RefHeading___Toc417708314)

Table 8 -- The Structure of the Turning Movement Information Table
[20](#__RefHeading___Toc417708315)

Table 9 -- The Structure of the Yearly Registration Table
[20](#__RefHeading___Toc417708316)

Table 10 -- The Structure of the Yearly Data Table
[20](#__RefHeading___Toc417708317)

Table 11 -- State Registration Table Indexes
[22](#__RefHeading___Toc417708318)

Table 12 -- State Master Table Indexes
[22](#__RefHeading___Toc417708319)

Table 13 -- Fixed Data Table Indexes [22](#__RefHeading___Toc417708320)

Table 14 -- Data Format Table Indexes [22](#__RefHeading___Toc417708321)

Table 15 -- Frame Index Table Indexes [22](#__RefHeading___Toc417708322)

Table 16 -- Turning Movement Information Table Index
[22](#__RefHeading___Toc417708323)

Table 17 -- Yearly Registration Table Index
[23](#__RefHeading___Toc417708324)

Table 18 -- Yearly Data Table Index [23](#__RefHeading___Toc417708325)

# List of Figures

Figure 1 -- The Existing Photo-logging System Data Flow
[2](#__RefHeading___Toc417708326)

Figure 2 -- Picking Operations [10](#__RefHeading___Toc417708327)

Figure 3 -- Index Building Flowchart [13](#__RefHeading___Toc417708328)

Figure 4 -- The Synchronization Process Flow Chart
[14](#__RefHeading___Toc417708329)

Figure 5 -- The Layered Database Structure For MMHIS
[15](#__RefHeading___Toc417708330)

Figure 6 -- Functional Dependencies of Databases in MMHIS
[21](#__RefHeading___Toc417708331)

Figure 7 -- Range of Services in a Multimedia Network \[3\]
[24](#__RefHeading___Toc417708332)

Figure 8 -- Buffering Scheme for Video Stream Playback
[29](#__RefHeading___Toc417708333)

Figure 9 -- Video Data Flow In The MMHIS For A State Highway Department
[32](#__RefHeading___Toc417708334)

Figure 10 -- Startup Screen of MMHIS [34](#__RefHeading___Toc417708335)

Figure 11 -- The Query Location Dialog Box
[34](#__RefHeading___Toc417708336)

Figure 12 -- The File Open Dialog Box [35](#__RefHeading___Toc417708337)

Figure 13 -- An Open Query in MMHIS [36](#__RefHeading___Toc417708338)

Figure 14 -- Font Selection Dialog Box
[37](#__RefHeading___Toc417708339)

Figure 15 -- Changing the Unit Through Menu Selection
[37](#__RefHeading___Toc417708340)

Figure 16 -- Changing the Site Data Update Rate
[38](#__RefHeading___Toc417708341)

Figure 17 -- Two Queries [39](#__RefHeading___Toc417708342)

Figure 18 -- Making Turns [40](#__RefHeading___Toc417708343)

Figure 19 -- Categorized Site Data Format
[40](#__RefHeading___Toc417708344)

Figure 20 -- User-defined Site Data Format
[41](#__RefHeading___Toc417708345)

Figure 21 -- Dialog Box Used to Define Site Data Format
[41](#__RefHeading___Toc417708346)

Figure 22 -- The Save As Dialog [42](#__RefHeading___Toc417708347)

Figure 23 -- Changing the Zooming Range for the Graphs
[42](#__RefHeading___Toc417708348)

Figure 24 -- The Dragable Vertical Bar in Graphing Windows
[43](#__RefHeading___Toc417708349)

Figure 25 -- Getting Information from the Map
[43](#__RefHeading___Toc417708350)

Figure 26 -- Directly Zooming on the Map
[44](#__RefHeading___Toc417708351)

Figure 27 -- A Zoomed-in Map with an Open Zooming Window
[44](#__RefHeading___Toc417708352)

Figure 28 -- The Index Building Interface
[46](#__RefHeading___Toc417708353)

# Introduction

Visual information is frequently used in highway departments for traffic
engineering and infrastructure management. Another type of information
is tabulated site data organized in traditional engineering databases on
pavement history and layer information, pavement width/type, average
daily traffic (ADT), accident history, and signing and marking
inventory, and others. These two types of information (roadway images
and traditional engineering database) can be of daily benefit to the
needs of various divisions in state highway departments. In order to
improve data accessibility in a highway department, it will be very
beneficial to combine these two information sources into one
comprehensive database that can be accessed simultaneously.

However, most existing photo logging systems used by various highway
departments are analog based and located at specific location(s) within
the department. Simultaneous multiple accesses to the video data are not
possible. Searching for site data is cumbersome. Traditional engineering
site data are contained separately from the video databases. There were
a few studies in an effort to exploit new technologies to improve the
accessibility and usability of video information collected from the
photo logging process. Wang et al. \[1\] present general concepts and
design issues for the development of a distributed multimedia based
highway information system (MMHIS) and discussed the economic and
technical feasibility of using digital video and new networking
technologies for such a system. It was concluded in that study that the
latest technology allows such a system to be developed cost-effectively.
This report summarizes the studies in the areas of high-speed
networking, video server technology, and data synchronization that are
essential for the implementation of an MMHIS. It is demonstrated that a
future digital video-based highway information system will be efficient
and productive through use of technologies such as Asynchronous Transfer
Mode (ATM) and state-of-the-art video server devices.

A working system has already been developed for the Arkansas State
Highway and Transportation Department (AHTD). The system has a user
intuitive interface. A guide on how to use this system is also given in
this document.

# History of Photo-logging System and Basic Requirement of MMHIS

## Problems with Existing Photo-logging Systems

Current existing photo-logging systems use data collection vehicles to
collect data on pavements and roadside structures and to take videos of
the right-of-way. The video information used by highway agencies is
stored in analog format and located at specific locations. The storage
media include tapes, films, and laser disks. Engineering site data are
stored in separate databases. Video playing devises are used to play the
highway videos. This is shown in Figure 1. Special-purpose software is
used in some existing systems to retrieve and present site data tables
to the user. The data in the database, however, are not well organized.
Some systems require the user to use general-purpose DBMS software to
open the table and query information. Others use file processing instead
of database management. The limitations of existing systems are
exhibited in the areas of accessibility, search capability of the video
library, and synchronization of video data with traditional engineering
site data. Users who are interested in a section of a road when viewing
the video have to go to another location to look for the corresponding
site data. The existing systems also lack multiple-user access
capability. Due to the analog nature of the video signals, it is
difficult to integrate the visual information with computer databases.
It is a time consuming process to look up and reassemble the video and
site data in different formats and from various sources.

![](media/image1.wmf){width="1.0in" height="0.4131944444444444in"}

![](media/image3.jpeg){width="1.0159722222222223in"
height="0.8958333333333334in"}

![](media/image5.wmf){width="1.4in" height="0.6in"}

![](media/image6.wmf){width="0.5291666666666667in" height="0.5in"}

[]{#__RefHeading___Toc417708326 .anchor}Figure 1 -- The Existing
Photo-logging System Data Flow

## Basic Features of MMHIS

A new system -- Multimedia-based Highway Information System (MMHIS) --
was developed in this project to solve the problems in existing
photo-logging systems. Technologies used in the new system include
digital video, high-speed video server, ATM networking, relational
database management system, and 3D-map rendering. MMHIS also uses a data
synchronization algorithm to synchronize the highway motion video with
the display of other data -- engineering site data, roughness and
rutting graphs, and location on the 3D-map. A high-speed network links
workstations with the MMHIS server so users can look at the
photo-logging video and the synchronized data sets without leaving their
offices. Because the engineering site data are stored in computer
databases, MMHIS can be easily customized to fit the need of different
departments.

Apart from easy data accessibility, data presentation in MMHIS is more
flexible than the old systems. An integrated environment hosts various
views that are used to display data from various sources. The views can
be customized to display a certain collection of fields in the data set.
It can display the data in either categorized or user-defined format.
Users can choose whether to use metric or imperial units in the data
display. When using the user-defined format, the order of the data
fields can also be customized.

With the technology advancement of satellite imagery and remote sensing,
vast amount of 3D earth surface data is readily available. Because all
inventory data from photo logging are location-specific and have spatial
characteristics, a terrain visualization interface was constructed for
MMHIS. Users can interact with a 3D digital map for the area of interest
and visually select data queries from this map. This visualization
interface allows users to rotate, zoom in and out, and pan around the
terrain surface of the area. The picking operation for the 3D map was
implemented using a specially designed picking algorithm. The 3D map can
be rotated freely within a certain range. The picking algorithm
guarantees that users can always click on the road in the rotated map
and get the correct location information. The 3D-map shows the terrain
surface relief when rotated to a low angle. In most cases, however,
users view the map from a right angle. In such cases, MMHIS uses special
algorithms to render the map so that the zooming, panning, and rendering
operations can be conducted with a very fast speed.

The Querying database in MMHIS is object-oriented. There are several
different ways to conduct a query in MMHIS. It does not require users to
be familiar with any general-purpose DBMS products. Users need only to
specify the location on a road by specifying the route number,
direction, and milepost, or by clicking on the map offered by MMHIS.
MMHIS provides highway engineers an efficient and effective tool in
analyzing road and roadside structures with instant accessibility to the
multimedia databases. This tool is not available to any highway
department in the United States at this time. The core technologies
developed for this system can be used in future generations of highway
information systems in any highway department.

# New Technologies of Digital Video and Geo-Referencing

## Digital Video for MMHIS

The video quality associated with consumer TV and video tapes, including
video from Super VHS and laser disks, is determined by the analog video
standards set by the National Television Standard Committee (NTSC) in
the early 1950s. Even though an analog video signal can be transmitted
and copied through narrow bandwidth, it is difficult to manipulate,
copy, and distribute without introducing electronic noise into the
original signal, resulting in the deterioration of image quality.
Without the use of high-end video production equipment, the integration
of analog video with other types of data, such as text and graphics, is
very difficult.

Additionally, in an MMHIS, multiple users need simultaneous and random
access to video data. For data stored in an analog system, multiple and
unsynchronized access to video data is a problem. For instance, it is
difficult to view two different sections of the same videotape
simultaneously, and then decide to freeze one while running the other.
Routing of multiple analog video data to users is also complicated. If
the video signal is presented in digital format, like the digital sound
in compact disks, it can provide much better image quality, can be
easily duplicated and can be incorporated into other media without
introducing artifacts or losing fidelity. Because digital video data is
stored in disk files, it is possible to allow simultaneous multiple
accesses to the same digital video files through computer networks.
Digital video is necessary when high fidelity, fast and multiple user
accesses are required of the MMHIS.

## Data Collection, Compression and Decompression (CODEC)

Presently the visual data is collected in a vehicle, such as a van, with
video capturing equipment. Normally, the visual data is recorded onto a
Y/C signal based tape (S-VHS or Hi-8mm) or laser disk. The video signal
is analog based with luminance and chrominance information separated.
The perceivable vertical resolution of the video data is about 400
lines. The recorded media are then categorized for viewing in the
office. To prepare the video for the MMHIS, the analog based video data
is digitized and becomes digital data sets that are directly manageable
with computers. The digital video is generated through a process called
encoding with source video data, such as tapes. One full color (8-bit
for each of red, green, and blue) digital image with a NTSC TV
resolution (640 x 480) requires approximately 0.92 megabyte of data
storage, resulting in about 27 megabytes of storage space for one second
of motion video. In addition, the input and output bandwidth of modern
microcomputers are not generally capable of processing this amount of
data per second. Therefore, data compression is needed to reduce data
storage requirements on the one hand, and to improve the data flow rate
on the other.

The amount of compression ranges from 2:1 to 200:1, depending on the
type of algorithm, the implementation of the algorithm, the level of
video quality, and the presence of hardware assistance. Most compression
algorithms are "lossy", meaning that some information is lost during the
compression of the data, due to the fact that the compression ratio
based on lossless encoding algorithms is low, around 2:1. The objective
for most applications is to retain visually faithful representations of
the original images and discard any visually insignificant information.
The process of compression and decompression (for playback) is called
CODEC for encoding and decoding. Some approaches require more operations
to be performed in encoding than in decoding. This type of CODEC is
referred to as asymmetrical. If both processes require the same amount
of processing, it is called symmetrical CODEC.

Motion JPEG (Joint Photographic Experts Group) and MPEG (Motion Picture
Experts Group) are the two dominant types of digital video CODECs, both
of which are used in this MMHIS research. The Joint Photographic Experts
Group (JPEG) developed the JPEG compression algorithm for still images
based on Discrete Cosine Transformation (DCT), the quantization approach
and Huffman encoding. The standard was then widely adopted as Motion
JPEG for video sequences, each frame of which is compressed based on the
JPEG standard. Motion JPEG allows easy random access to any frame in a
digitized sequence. Compression for Motion JPEG is conducted exclusively
on redundant data in individual frames without condensing any data
between frames. Hardware based JPEG CODEC's can capture full-screen, 30
frame per second video in real time. When a high compression ratio (over
20:1) is not required, this symmetrical CODEC is very effective in
preserving the details and fidelity of single video frames.

Unlike JPEG, which condenses information only within each frame, the
standard developed by the Motion Picture Experts Group, MPEG, compresses
information based on data within a frame and frame to frame motion. It
should be noted that the compression within frames in MPEG is also based
on DCT and related algorithms.

MPEG allows compression ratios over 100:1 while still retaining good
visual quality. Due to its high compression ratio, MPEG is a desirable
delivery format for applications that require narrow bandwidth
transmission, such as CD-ROM and video networks. However, due to the
asymmetric nature of MPEG, the encoding process requires very high
computing power. For example, a state-of-the-art MPEG encoding device
can consist of over a dozen RISC based compression processors. The
decoding process of MPEG needs relatively less computing power. At
similar levels of video quality, a Motion JPEG stream will require a
much higher data rate than an MPEG compressed stream. Current available
MPEG systems are classified into the categories of MPEG1 and MPEG2 with
MPEG1 being used for CD storage and the Internet, and MPEG2 being used
for studio quality video and satellite digital TV systems.

## Geo-referencing Technologies

The 3D map interface of the MMHIS uses a geo-referenced map to show the
location of the video on the map and allows users to query data on any
point on the map. The information about the location of any point on the
map is displayed in a pop-up window when the point is clicked with the
right button of the mouse. In addition, if the clicked point is near a
road, the route number, direction, and milepost of the road at that
point are also shown.

The 3D map of MMHIS is rendered based on information stored in the
3D-map database. Separate files are used to store different data in the
3D-map database. These files are listed in Table 1.

  ---------------------------- ------------------------------------------
  Database File                Description

  DEM                          The digital elevation model that is used
                               by MMHIS to render the terrain surface

  2D surface map               3D map viewed from a right angle

  2D coordinate maps           Coordinate maps that are used for 2D
                               picking operations

  2D zoom surface map          Map used to show the zooming interface

  2D zoom coordinate maps      Coordinate maps that are used for zooming
                               interface picking operations

  Raster map                   Map that shows surface features

  Shape                        Rendered shading for the terrain surface

  Location                     File that stores route number, direction,
                               and milepost information
  ---------------------------- ------------------------------------------

[]{#__RefHeading___Toc417708308 .anchor}Table 1 -- MMHIS 3D Map
Databases

### 3D Database File Structures

Digital Elevation Models (DEM) are essential to the rendering of the 3D
surface of the earth. The DEMs used in the MMHIS were obtained from the
United States Geological Survey (USGS). They were then converted to
MMHIS specific file formats to provide for fast information retrieval.
The conversion is based on the understanding of the original USGS DEM
file format. Several utility programs were developed to aid this
conversion. The USGS DEM file format is a general format that is
suitable for a variety of different DEMs. Because MMHIS only uses one
type of DEM, it makes sense to simplify the file format and make access
to the data more efficiently. In the mean time, the file size can be
reduced to the minimum size possible and hence save storage space on the
host computer. Twenty-four 1-degree DEMs are needed to cover the whole
State of Arkansas. Instead of using 24 separate DEM files as the data
source, MMHIS combined all 24 DEM files into one file. There are three
different records in the combined DEM file. The first record stores the
origin of the area that is covered by the DEM. It contains two
floating-point numbers representing the longitude and the latitude of
the origin (southwest corner coordinates) in degrees. The second record
contains integers representing the number of grid points along both the
longitude and latitude lines. The third record contains the elevations
in meters along the profiles organized from south to north and from west
to east. The numbers are stored in the internal integer format of the
host operating system.

The rendering of a 3D map is time consuming on high-end desktop
computers. Users of MMHIS normally want to scan the whole map quickly,
locate the spot on the map, and then decide to see details of the
terrain surface of that particular area of interest. To reduce the time
for rendering the map and still offer the power to show the 3D-terrain
surface, MMHIS treats the special case of 2D rendering separately. This
requires a separate database to be setup to store the 2D surface map.
Windows has powerful Device-Independent Bitmap (DIB) manipulation API
functions built in. To take advantage of that, MMHIS stores the 2D
surface map in Windows DIB format.

The 2D coordinate maps are saved in two files---one for longitude, one
for latitude. These files are used to implement the picking operation in
2D special cases. The longitude and latitude of any point on the map can
be identified by querying the above two files.

The 2D zoom surface map is similar to the 2D surface map file. It is
used to speed up the zooming control in the MMHIS's map interface. The
file is in Windows DIB format. The 2D zoom coordinate maps are similar
to the 2D coordinate maps. These files are used in the zooming control
to implement the picking operation.

The raster map of Arkansas is used in a texture mapping process to
project the 2D map to the 3D-terrain surface. This file records the
intermediate result of this mapping. The file contains three records.
The first record stores the origin of the area. Two floating-point
numbers are used in this record to give the longitude and the latitude
of the origin. The second record stores the number of grid points along
the longitude and latitude lines. The file uses the same grid system as
the DEM. The third record stores the texture mapping results. It is an
array of red, green, and blue (RGB) values ordered along the grid lines
from south to north, west to east. Each RGB value contains three bytes
that represent the mapped red, green, and blue color element on that
grid point.

MMHIS renders the 3D-terrain surface with different shades, showing the
shape of the surface with light effects. With real-time rendering, the
shading process is very slow. Because the terrain surface shape is
fixed, the shading of all points in the area is saved to an intermediate
file so that the data do not have to be generated each time the scene is
rendered. The shape information file is used for this purpose. The
file's structure is similar to the raster map information file. The only
difference is that instead of saving an array of three bytes
representing RGB values in the third record, this file saves a byte
array. Each element of the array represents the corresponding shading of
the grid points.

Note that this file does not record things such as hidden surface
information. MMHIS deals with the issue of hidden surface removal using
other tools. To show 3D objects' positions, real-time rendering is
conducted when the map is displayed. The real rendering process uses a
less computation-intensive lighting model so that the scene can be
efficiently rendered.

The route numbers, directions, and mileposts of grid points on roads are
saved in the location file. MMHIS uses this information to decide the
query location of a point on the map. There are three records in this
file. The first two records are the same as those in the shape
information file. The third record contains an array of integer pairs
representing the route and milepost of each grid points. The route is
the RowID field value in the state master table (refer to later sections
for database structures).

### Generating the 3D Map Database

The conversion from USGS 1-degree DEMs to the MMHIS DEM file requires
two steps, utilizing two special utility programs developed specifically
for this purpose. These two programs are not built into the MMHIS
integrated environment because the conversion takes place only once. The
first step converts individual USGS 1-degree DEM files into individual
MMHIS DEM files using a vertical scale factor of one. The second step
combines these small files into the final large DEM file.

The 2D surface map is a special case of viewing the 3D surface map from
the right angle. The 2D surface map is generated by rendering the 3D
surface map using the right angle. It is saved in the DIB format to the
2D surface map file.

The 2D coordinate maps are rendered using the more general technique of
rendering the 3D coordinate map with a viewing angle of 90° (right
angle). The rendered map is saved in the DIB format to the 2D coordinate
map files.

The process of creating these two files is the same as the process of
creating the 2D surface map and the 2D coordinate maps; with the use of
different parameters. The resultant files are saved to appropriate
files.

MMHIS uses a 2D map that was scanned from a paper map as the basis for
the features of the 3D map. Information from the 2D map is used in the
final rendering of the 3D map. It is also used in the road digitizing
process. The resolution of this map is smaller than the resolution
offered by the DEM.

The creation of the raster map involves a texture mapping (or
projection) process. The projection algorithm is described below.

-   Loading the 2D map and the DEM

This step loads the 2D map into memory. The raw data of the image is
separated to simplify the projection process. The MMHIS DEM file is also
loaded for use in the rendering process.

-   Matching the 2D raster map with the MMHIS rendered region

In this step, the longitude and latitude lines are rendered and overlaid
to the 2D map. The purpose is to find out the correct transformation
factors so that the rendering results match the corresponding lines on
the 2D map. During the matching process, transformation factors are
interactively adjusted and the longitude and latitude grids are rendered
after each adjustment. The result is shown on screen and is visually
compared with the lines on the 2D map. The process stops after a
satisfactory match is reached.

-   Rendering the 3D-terrain surface using lighting effects

Using the results from the previous step to conduct the transformation,
the 3D-terrain surface is then rendered to a buffer that has the same
dimension as the 2D-raster map. Because of the large size of the area, a
memory mapped file kernel object is used as the virtual memory for the
rendering buffer. DEM data are used in this step.

-   Reading the DEM records and match each grid points to the results in
    the previous two steps

In this step, the DEM records are scanned and the view-port coordinates
for the grid points are calculated with the OpenGL raster position
functions. The view-port coordinates are used to get the colors of
corresponding pixels in both the 3D-terrain surface rendering buffer and
the 2D-raster map. These colors are used to fill the records of the
raster map and shape information files.

Roads on the 2D-raster map are digitized and saved in the location
information file. The digitization is an interactive process. The
following steps are used in this process.

-   Prepare the 2D-raster map and the longitude and latitude grid
    buffers

The digitization process uses the 2D-raster map to show the location of
roads. It requires the user to interactively specify points on the road
on the 2D-raster map. The map is loaded into one buffer of the program.
Two other buffers containing the corresponding longitude and latitude
grid information can either be rendered directly or loaded from disk
files (if one has already been created). These two buffers are used to
get the grid coordinates of points on the 2D-map.

-   Define points of a new road

A temporary file is created in this step to save the coordinates of
points on the road. The program checks for mouse click messages after
the above file is created. The points clicked by mouse are then linked
to form a line representing the road. Because points clicked by the
mouse does not cover all points on the road, Windows dynamic data
analysis function ::LineDDA() is called to retrieve all pixels on the
road. The view-port coordinates of all pixels on the road are saved into
the temporary file.

-   Correlate mileposts with grid coordinates

The coordinates saved in the above file are checked against the pixel
information in the two grid coordinate buffers to get the longitude and
latitude of the points. The results are saved in the same file.

-   Specify mileposts for key points

Similar to the video frame index building process, this step allows
users to interactively specify the milepost of certain points (called
key points) on the road. These points will be matched exactly to the
mileposts specified.

-   Update database

Linear stretch is used to calculate the mileposts of every grid points
and the result is saved in the last two fields of the fixed data table
corresponding to the road.

### Picking Operations

The map module allows users to click on the map and shows a small popup
window with location information in it. If the point clicked is a point
on a highway section and is registered in the database, it also displays
a menu showing the point's corresponding route number, direction, and
milepost. The operation is called *picking*. The picking can happen
anywhere on the map.

MMHIS creates two buffers for picking operations. Instead of rendering
the same scene to two different buffers and specifying the names of the
objects, the MMHIS renders the main scene only once. The MMHIS specific
C++ class cmaptools handles rendering the picking buffers in a
simplified way---it renders the location information directly into the
picking buffers. cmaptools does not use name stacks as normal OpenGL
programs do. It uses *colors* to represent longitude and latitude grid
numbers in its picking buffers. When a point on the map is clicked by
the user, the corresponding two points in the two picking buffers are
checked. The coordinates of the clicked point can be obtained by
decoding the colors of the corresponding points in the picking buffers.
This decoding process is the reverse of the rendering process. cmaptools
does not use any lighting effects when it renders the picking buffers.
This ensures the color of each pixel in the picking buffer is the one
specified during the rendering process. The cmaptools does not render
anything on the screen. This ensures that the actual color depth of the
display device does not affect the color depth requirement of the
picking buffers. Figure 2 shows MMHIS's picking mechanism.

[]{#__RefHeading___Toc417708327 .anchor}Figure 2 -- Picking Operations

After the coordinates of a point on the map are obtained, MMHIS obtains
the elevation of the point from the DEM data file and displays the
location information in a small pop-up window. The program then checks
all the points in the vicinity using the data in the location
information file. The route (represented by the RowID field of the state
master table) and milepost can be obtained from this file if the point
is registered in the digitizing process. With this information in hand,
the direction information can be queried out from the state master
table. The returned data is used to construct a context menu to show the
position of the point.

### Location Synchronization with Video and Site Data

When a query is going on, a location indicator (a small flashing red
dot) is displayed on the map to show the current vehicle location. The
location indicator goes along the highway on the map as the video plays.
The synchronization timer handler queries the current vehicle location
from the fixed data table and passes the query result to the 3D-map
sub-module. The map module then finds the screen coordinates of the
current vehicle location. MMHIS maintains a 3D position in window
coordinates. (This is handled internally by the OpenGL engine.) This
position, called the *raster position*, is used to position pixel and
bitmap write operations. It is maintained with sub-pixel accuracy. The
current raster position consists of three window coordinates (*x*, *y*,
*z*), a clip coordinate value (*w*), an eye coordinate distance, a valid
bit, and associated color data and texture coordinates. The *w*
coordinate is a clip coordinate, because *w* is not projected to window
coordinates. MMHIS converts world coordinates to window coordinates by
calling appropriate API functions. The converted window coordinates are
used to display the location indicator on the map.

# Data Synchronization Algorithms and Implementation

## The Preparation of Video Frame Index

Video frame indexes were created with the MMHIS Index Building module.
The index building process is divided into the following steps.

-   Obtaining information. In this step, necessary information is
    collected in the *Building Index* dialog box. The fields are listed
    in Table 2.

  -------------------- --------------------------------------------------
  Field                Explanation

  Video File Name      The name of the video file for which frames will
                       be indexed

  Video Start Frame    Frame number corresponding to the beginning
                       milepost

  Video End Frame      Frame number corresponding to the ending milepost

  Route Number         Route number of this section

  Direction            Direction of this section

  Start Milepost       Starting point of this section

  End Milepost         End point of this section

  Key points           Mileposts of points that corresponds to known
                       frame numbers

  Turning points       Destination route numbers, directions and
                       mileposts of turning points
  -------------------- --------------------------------------------------

[]{#__RefHeading___Toc417708309 .anchor}Table 2 -- Index Building Module
Input

-   The key points specified by the user are used to define subsections
    of the highway section covered by the current video. Each subsection
    begins at one key point and ends at the next key point. That is, in
    each subsection only the first milepost and the last milepost have
    corresponding video frame numbers specified. Video frame numbers
    corresponding to the rest of mileposts are calculated by using the
    linear interpolation method. The speeds of the vehicle when it took
    the video are recorded into the main data table. The speed data are
    used as the determining factors.

The above method guarantees that key points are exactly indexed with the
frame number specified. This is especially useful when the speed data is
not accurate enough to be used as the sole factor to interpolate values.
If the total accuracy is guaranteed, only the starting point and end
point of the whole section need to be defined as key points.

To describe the above algorithm mathematically, suppose for a subsection
the starting milepost is *s*, which corresponds to frame number *fs*,
and the end milepost is *e*, which corresponds to frame number *fe*. The
number of mileposts in this subsection *n* can be calculated as

$n = \frac{e - s}{\text{step}} + 1$,

in which *step* is the distance between consecutive mileposts. In the
current database, the value of step is 25 meters. Suppose the speed
value for milepost *i* (*i* is *1 -- n-1*) is *speed(i)*. The
corresponding frame number is *frame(i)*. The traveling time for the
video to cover this subsection *T* is calculated as

$T = \sum_{j = 1}^{n - 1}\frac{\text{step}}{\text{speed}(j)}$.

The frame numbers for the rest of mileposts are calculated as

$\text{frame}(i) = \frac{(\text{fe} - \text{fs})}{T}\sum_{j = 1}^{i}\frac{\text{step}}{\text{speed}(j)} + \text{fs}$.

Database updates are involved in the index building module. Because the
Microsoft Access ODBC driver supports database updates, it is just a
simple matter of calling the appropriate update functions with proper
SQL commands to finish building the index. The index building process is
shown in Figure 3.

[]{#__RefHeading___Toc417708328 .anchor}Figure 3 -- Index Building
Flowchart

## The Synchronization of Video and Site Data Display

When MMHIS is started with a query, the information displayed is all
synchronized. That is, when the video is playing, data displayed in all
other windows change dynamically with the video frames. The view window
of the MMHIS control module has a timer set up at creation time. This
timer, called the *synchronization timer*, is used to synchronize the
display of site data with the video. The synchronization timer handler
in the MMHIS control module does not actually find the correct data and
display them. Instead, it acts as a director to orchestrate all
sub-modules of MMHIS.

The synchronization process uses a frame range to check if the current
frame of the video is still in the range for the current milepost. The
range is updated when the site data and the video frame are
synchronized. The first time a query is started, this range is set to an
impossible range to guarantee that the synchronization operation is
applied upon initialization. The synchronization process is shown in
Figure 4.

[]{#__RefHeading___Toc417708329 .anchor}Figure 4 -- The Synchronization
Process Flow Chart

# Database Structures of MMHIS

There are four database layers in the MMHIS. The first layer contains
the state registration table. The second layer contains the state master
table. The third layer contains tables that store engineering site data,
frame index, turning movement information, and the data display format.
The fourth layer contains the yearly data table. These tables are used
to store data collected in different years for the roads. This layered
structure is shown in Figure 5.

[]{#__RefHeading___Toc417708330 .anchor}Figure 5 -- The Layered Database
Structure For MMHIS

## The State Registration Table

The state registration table is used to register all the states in the
US. Each state has a record in this table. The structure of this table
is listed in Table 3. The primary key for this table is StateName. The
field StateMasterTableExist determines if a corresponding table (state
master table) in the second layer exists for the state. Other fields
specify the map database (which is saved separately from the database
for engineering site data), and basic attributes of the map.

  ------------------------ ----------------- ----------------------------
  Field Name               Data Type         Short Description

  StateName                Text              State Name

  StateShortName           Text              Abbreviation of State Name

  StateMasterTableExist    Boolean           Yes if the state has a
                                             master table; No if not.

  MapPath                  Text              Path for all the files
                                             relating to map rendering

  DemFileName              Text              Name of the digital
                                             elevation modal file

  MapFileName              Text              Name of the raster map file

  ShapeFileName            Text              Name of the rendered terrain
                                             shape file

  LocationInfoFileName     Text              Name of the file that
                                             contains location
                                             information

  FlatMapFileName          Text              Name of the 2D map file

  FlatXFileName            Text              Name of the 2D x-coordinate
                                             file

  FlatYFileName            Text              Name of the 2D y-coordinate
                                             file

  ZoomMapFileName          Text              Name of the zoom map file

  ZoomXFileName            Text              Name of the zoom
                                             x-coordinate file

  ZoomYFileName            Text              Name of the zoom
                                             y-coordinate file

  InitZoom                 Number            Zoom factor for the whole
                                             state

  InitCenteri              Number            Initial x-coordinate of the
                                             center point

  InitCenterj              Number            Initial y-coordinate of the
                                             center point

  FlatMapWidth             Number            Width of the 2D map

  FlatMapHeight            Number            Height of the 2D map
  ------------------------ ----------------- ----------------------------

[]{#__RefHeading___Toc417708310 .anchor}Table 3 -- The Structure of
State Registration Table

## The State Master Table

The state master table registers all the roads in the corresponding
state. Each record in this table represents a unique route. The
structure of this table is shown in Table 4. The field RowID (RoadID
attribute of the entity ROAD) is the primary key for this table. The
values of RouteNumber and Direction can also uniquely identify a record
in this table. They are also used as keys for this table. Other fields
represent the existence of other tables in the third layer.

Attention should be paid to the DatabaseFileName field. This field
specifies the actual database that hosts the corresponding tables in the
third layer. As pointed out later, the MMHIS uses Microsoft Access® DBMS
as the physical implementation platform of the database system. The
Microsoft Access database has a limitation on the number of tables in
each database. Putting all of the tables in one database may cause
problems since the total number of tables may well exceed the limit.

Including the VideoFilePath field allows the system to put video files
for different states to different locations and makes it easier to
manage the video files.

  -------------------------------- -------------- ------------------------
  **Field Name**                   **Data Type**  **Short Description**

  RowID                            Number         Record serial number

  RouteNumber                      Text           Route number

  Direction                        Text           Direction

  FromMilePost                     Number         Start milepost of the
                                                  road

  ToMilePost                       Number         End milepost of the road

  FixedDataTableExist              Boolean        The existence of the
                                                  fixed data table

  FrameIndexTableExist             Boolean        The existence of the
                                                  frame index table

  TurningMovementTableExist        Boolean        The existence of the
                                                  turning movement
                                                  information table

  YearDataRegistrationTableExist   Boolean        The existence of the
                                                  yearly data registration
                                                  table

  SiteDataFormatTableExist         Boolean        The existence of the
                                                  site data format table

  DatabaseFileName                 Text           Database file name for
                                                  all the above mentioned
                                                  tables

  VideoFilePath                    Text           Path for the video files
                                                  for the current route
  -------------------------------- -------------- ------------------------

[]{#__RefHeading___Toc417708311 .anchor}Table 4 -- The Structure of the
State Master Table

## Fixed Data Table

This table stores the basic information for each route. The data stored
in the table normally remain the same for a certain period of time. The
table only stores the latest values for the fields. The fields
LongitudeGrid and LatitudeGrid are used to store the spatial location
for each milepost. This is used in the MMHIS to mark the location of the
current point on the map. In this table, the MilePost field is the
primary key. The structure of this table is listed in Table 5.

  ----------------------- --------------------- --------------------------
  Field Name              Data Type             Short Description

  MilePost                Number                Milepost

  Lane                    Number                Number of lanes

  PavementWidth           Number                Total width of the
                                                pavement

  LeftShoulder            Number                Width of the left shoulder

  RightShoulder           Number                Width of the right
                                                shoulder

  District                Text                  District

  Area                    Text                  Area

  Region                  Number                Region

  ADT                     Number                Average daily traffic

  ADL                     Number                Average daily load

  GrowthFactor            Number                Growth factor

  StructureNumber         Number                Structure number of the
                                                pavement

  Project                 Text                  Project

  Year                    Number                Year

  Layer1                  Text                  Layer 1 Material

  Thickness1              Number                Thickness of Layer 1

  Layer2                  Text                  Layer 2 Material

  Thickness2              Number                Thickness of Layer 2

  Layer3                  Text                  Layer 3 Material

  Thickness3              Number                Thickness of Layer 3

  Layer4                  Text                  Layer 4 Material

  Thickness4              Number                Thickness of Layer 4

  Layer5                  Text                  Layer 5 Material

  Thickness5              Number                Thickness of Layer 5

  Layer6                  Text                  Layer 6 Material

  Thickness6              Number                Thickness of Layer 6

  Rate                    Number                Rate

  Speed                   Number                Speed of the vehicle when
                                                the data was collected

  LongitudeGrid           Number                Longitude coordinate of
                                                the current point

  LatitudeGrid            Number                Latitude coordinate of the
                                                current point
  ----------------------- --------------------- --------------------------

[]{#__RefHeading___Toc417708312 .anchor}Table 5 -- The structure of
fixed data table

## The Data Format Table

The table contains information on the format of the site data display.
Users can modify the contents of this table to change the output format
of the site data. The primary key for this table is FieldName. The
values of this field correspond to the fields in the fixed data table
and the yearly data table (mentioned later). MMHIS can use two unit
systems to display site data. To allow users to decide what to display
for the units, several fields are included in this table specifying the
name of the unit and the conversion factor for the unit. The structure
of this table is listed in Table 6.

  ----------------------- ------------------- ----------------------------
  Field Name              Data Type           Short Description

  FieldName               Text                Field name in the database
                                              tables

  Caption                 Text                Field caption shown in the
                                              site data view

  Type                    Text                Data type of the current
                                              field

  Unitless                Boolean             Whether or not the field has
                                              a unit

  MetricsUnitName         Text                Unit name for the field when
                                              metric unit system is chosen

  MetricsConverter        Number (single)     Multiplier for converting
                                              the field value to metric
                                              system values

  ImperialUnitName        Text                Unit name for the field when
                                              imperial unit system is
                                              chosen

  ImperialConverter       Number (single)     Multiplier for converting
                                              the field value to imperial
                                              system values

  Format                  Text                Format specifier for the
                                              field data

  GroupName               Text                Name of the category to
                                              which the current field
                                              belongs

  DefaultDisplayOrder     Number (integer)    Default order to display the
                                              fields

  SourceTable             Text                Name of the table to which
                                              the current field belongs
  ----------------------- ------------------- ----------------------------

[]{#__RefHeading___Toc417708313 .anchor}Table 6 -- The Structure of the
Data Format Table

## The Frame Index Table

The frame index table contains the synchronization information that is
used to synchronize the site data display with the video display. The
MilePost field is used as the primary key for this table. Since on the
Windows NT ® operating system there is a limit on the size of video
files, multiple video files are normally needed for a road. The
VideoFileName field is used to store the file names for the videos. The
structure of this table is shown in Table 7.

  ------------------------ ----------------------- -----------------------
  Field Name               Data Type               Short Description

  MilePost                 Number (long integer)   Milepost

  VideoFileName            Text                    Name of the video file

  StartFrameNumber         Number (long integer)   Start frame for the
                                                   current milepost

  EndFrameNumber           Number (long integer)   End frame for the
                                                   current milepost

  TurningMovementFlag      Number (byte)           Flag for turning
                                                   movement
  ------------------------ ----------------------- -----------------------

[]{#__RefHeading___Toc417708314 .anchor}Table 7 -- The Structure for the
Frame Index Table

## The Turning Movement Information Table 

The turning movement information table contains information on the
location and destination of turning points. The structure of this table
is shown in Table 8.

  ------------------- ----------------------- ----------------------------
  Field Name          Data Type               Short Description

  MilePost            Number (long integer)   Milepost

  LeftState           Text                    Left turn destination state

  LeftRowID           Number (long integer)   Left turn destination route

  LeftMilePost        Number (long integer)   Left turn destination
                                              milepost

  ThroughState        Text                    Through destination state

  ThroughRowID        Number (long integer)   Through destination route

  ThroughMilePost     Number (long integer)   Through destination milepost

  RightState          Text                    Right turn destination state

  RightRowID          Number (long integer)   Right turn destination route

  RightMilePost       Number (long integer)   Right turn destination
                                              milepost
  ------------------- ----------------------- ----------------------------

[]{#__RefHeading___Toc417708315 .anchor}Table 8 -- The Structure of the
Turning Movement Information Table

## The Yearly Registration Table

The year registration table has one record for each year that has yearly
specific data. Each record in this table has a corresponding table in
the fourth layer. The structure of this table is listed in Table 9.

  ------------------- ----------------------- ----------------------------
  Field Name          Data Type               Short Description

  Year                Text                    The year number

  LogFromMilePost     Number (long integer)   Starting log milepost

  LogToMilePost       Number (long integer)   End log milepost
  ------------------- ----------------------- ----------------------------

[]{#__RefHeading___Toc417708316 .anchor}Table 9 -- The Structure of the
Yearly Registration Table

## The Yearly Data Table

The yearly data table contains each year's data. The structure of this
table is shown in Table 10.

  ------------------ ------------------------ ----------------------------
  Field Name         Data Type                Short Description

  MilePost           Number (long integer)    Milepost

  Cracking           Number (single)          Cracking value

  RoughnessLeft      Number (single)          Left wheel roughness

  RoughnessRight     Number (single)          Right wheel roughness

  M                  Number (integer)         Field taken from Arizona
                                              database

  RuttingLeft        Number (single)          Left wheel rutting

  RuttingRight       Number (single)          Right wheel rutting

  Patching           Number (integer)         Patching

  Flushing           Number (single)          Flushing

  ADT                Number (long integer)    Average daily traffic
  ------------------ ------------------------ ----------------------------

[]{#__RefHeading___Toc417708317 .anchor}Table 10 -- The Structure of the
Yearly Data Table

## Functional Dependencies of Databases

The functional dependencies are shown in Figure 6. The above database
schema design conforms the normalization criteria 1NF, 2NF, and 3NF. It
has dependency preserving and lossless join properties.

**State Registration Table**

**State Master Table**

**Fixed Data Table**

**Data Format Table**

**Frame Index Table**

**Turning Movement Information Table**

**Yearly Registration Table**

**Yearly Data Table**

[]{#__RefHeading___Toc417708331 .anchor}Figure 6 -- Functional
Dependencies of Databases in MMHIS

## Database Indexes

MMHIS uses database indexes to speed up queries. The primary key in each
table is automatically indexed. Additional indexes are added to each
table according to the needs of queries. The indexes for the database
tables in MMHIS are shown in Table 11 -- Table 18.

  ---------------- ---------------- ----------- --------- -------- ------------
  Index Name       Field Name       Sort Order  Primary   Unique   Ignore Nulls

  PrimaryKey       StateName        Ascending   Yes       Yes      No

  StateShortName   StateShortName   Ascending   No        Yes      No
  ---------------- ---------------- ----------- --------- -------- ------------

[]{#__RefHeading___Toc417708318 .anchor}Table 11 -- State Registration
Table Indexes

  ------------------- ------------- ----------- --------- -------- ------------
  Index Name          Field Name    Sort Order  Primary   Unique   Ignore Nulls

  PrimaryKey          RowID         Ascending   Yes       Yes      No

  RouteNumber         RouteNumber   Ascending   No        No       No

  RouteNumberAndDir   RouteNumber   Ascending   No        No       No

                      Direction     Ascending                      
  ------------------- ------------- ----------- --------- -------- ------------

[]{#__RefHeading___Toc417708319 .anchor}Table 12 -- State Master Table
Indexes

  --------------- --------------- ----------- --------- -------- ------------
  Index Name      Field Name      Sort Order  Primary   Unique   Ignore Nulls

  PrimaryKey      MilePost        Ascending   Yes       Yes      No

  LatitudeGrid    LatitudeGrid    Ascending   No        No       No

  LongitudeGrid   LongitudeGrid   Ascending   No        No       No
  --------------- --------------- ----------- --------- -------- ------------

[]{#__RefHeading___Toc417708320 .anchor}Table 13 -- Fixed Data Table
Indexes

  --------------------- --------------------- ----------- --------- -------- -----------
  Index Name            Field Name            Sort Order  Primary   Unique   Ignore
                                                                             Nulls

  PrimaryKey            FieldName             Ascending   Yes       Yes      No

  DefaultDisplayOrder   DefaultDisplayOrder   Ascending   No        Yes      No
  --------------------- --------------------- ----------- --------- -------- -----------

[]{#__RefHeading___Toc417708321 .anchor}Table 14 -- Data Format Table
Indexes

  ------------------ ------------------ ----------- --------- -------- -----------
  Index Name         Field Name         Sort Order  Primary   Unique   Ignore
                                                                       Nulls

  PrimaryKey         MilePost           Ascending   Yes       Yes      No

  EndFrameNumber     EndFrameNumber     Ascending   No        No       No

  StartFrameNumber   StartFrameNumber   Ascending   No        No       No

  VideoFileName      VideoFileName      Ascending   No        No       No

  VideoAndFrame      VideoFileName      Ascending   No        No       No

                     StartFrameNumber   Ascending                      

                     EndFrameNumber     Ascending                      

  MilePostAndFrame   MilePost           Ascending   No        No       No

                     StartFrameNumber   Ascending                      
  ------------------ ------------------ ----------- --------- -------- -----------

[]{#__RefHeading___Toc417708322 .anchor}Table 15 -- Frame Index Table
Indexes

  ------------- ------------ ----------- ---------- --------- -------------
  Index Name    Field Name   Sort Order  Primary    Unique    Ignore Nulls

  PrimaryKey    MilePost     Ascending   Yes        Yes       No
  ------------- ------------ ----------- ---------- --------- -------------

[]{#__RefHeading___Toc417708323 .anchor}Table 16 -- Turning Movement
Information Table Index

  -------------- ------------ ----------- --------- -------- -------------
  Index Name     Field Name   Sort Order  Primary   Unique   Ignore Nulls

  PrimaryKey     Year         Ascending   Yes       Yes      No
  -------------- ------------ ----------- --------- -------- -------------

[]{#__RefHeading___Toc417708324 .anchor}Table 17 -- Yearly Registration
Table Index

  ------------- ------------ ----------- ---------- --------- -------------
  Index Name    Field Name   Sort Order  Primary    Unique    Ignore Nulls

  PrimaryKey    MilePost     Ascending   Yes        Yes       No
  ------------- ------------ ----------- ---------- --------- -------------

[]{#__RefHeading___Toc417708325 .anchor}Table 18 -- Yearly Data Table
Index

# Network and Hardware Issues in a Production Environment

## MMHIS Network Performance Requirements

A single digital video stream based on the National Television Standard
Committee (NTSC) standard has a data rate of about 200 kilobytes per
second for MPEG1, 0.5 to 2 megabytes per second (MB/s) for most MPEG2
signals, and 3 to 5 MB/s for Motion JPEG. Common networks based on Token
Ring or Ethernet have the shared data bandwidth of 16M bit/sec and 10 M
bit/sec (2 MB/s and 1.25 MB/s) respectively. The effective actual
bandwidth available to a station can be much less than the specified
rate of 16 Mb/s or 10 Mb/s, due to (1) the nature of bandwidth sharing
for both Ethernet and Token Ring, (2) network overhead. In addition, the
two types of networks are optimized for carrying packet and burst data,
and do a poor job of carrying full-motion video that requires guaranteed
bandwidth. In order to provide multiple streams of video data (more than
10), the throughput of the traditional network needs to be improved and
the bandwidth for individual stations needs to be guaranteed.
Furthermore, it is required that video streams be delivered in a
particular order with very small and consistent latency. Otherwise,
frame drop and un-synchronization would occur. Ethernet, Token Ring, and
Fiber Distributed Data Interface (FDDI) use shared-medium and are not
capable of carrying motion video in a timely fashion. Therefore, the
challenge is to design a proper network to both provide high bandwidth
and guarantee video delivery.

The MMHIS capable computer network should be able to carry a number of
services, including low speed data transmission for regular data sets
and mail, medium speed data transmission for CAD design files, and high
speed data transmission for the distribution of high quality video
footage of highway sections. Therefore, the network system cannot be
designed specifically for one service. Figure 7 shows a range of
services with an estimated bit rate of a few bit/s up to some hundreds
of Mb/s. The holding times (continuous transmission period) vary from
seconds to hours.

[]{#__RefHeading___Toc417708332 .anchor}Figure 7 -- Range of Services in
a Multimedia Network \[3\]

Ethernet and Token Ring technologies are limited in their bandwidth and
capabilities of ensuring timely delivery of multimedia data. Recently,
switched Ethernet has become a cost-effective approach to increase the
available bandwidth from a station to a server. In a switched Ethernet
based network, every station has a dedicated bandwidth of 10 Mb/s to the
switch, which has a bigger data pipe to the server with 100 Mb/s
bandwidth. The 100 Mb/s Ethernet link from the server to the switch is
called fast Ethernet. Although data throughput is increased in the
switched Ethernet, the inherent limitations of Ethernet still remain in
area of time transparencies. For instance, when an MPEG2 video stream at
4 to 8 Mb/s is requested from a client, and at the same time a CAD file
gets transmitted from the server to another client, there is no
guarantee that the video stream will be delivered uninterrupted. Most
likely jitters will occur to the video stream at the client station. In
reality, there could be many data transmissions underway at a particular
point of time in the network. Apparently, even switched Ethernet is not
a good solution to the problem of providing guaranteed bandwidth for the
MMHIS system or any types of distributed multimedia services with a high
video quality requirement.

In the last decade, tremendous research has been conducted by both
telecommunication and computer network industries in the area of
providing high quality data service with guaranteed bandwidth in
computer networks. A technology called Asynchronous Transfer Mode (ATM)
has emerged as the dominant approach to solve wide and local area data
transmission problems by providing very high speed connections with
guaranteed bandwidth for various types of services, including the
bandwidth hungry video/audio transmissions.

## Asynchronous Transfer Mode (ATM) and Gigabit Ethernet

ATM is an extremely fast, high bandwidth, packet-switching technology
created by the telecommunication industry. In an ATM environment,
computers are connected through adapter cards and network wire to a
central ATM switch. ATM breaks all traffic (voice, video or data) into
equal sized 53-byte short packets, known as cells. Each cell has a
5-byte header. Therefore, the user data in each cell amounts to 48 bytes
or 90% of the total data. The size of 48-byte information field in the
ATM cell was determined through compromise by the two industry groups in
Europe and the US, which preferred a 32-byte size cell and 64-byte size
cell respectively. In return for the 10% overhead, ATM brings two
benefits. First, its short, fixed length cell makes ATM better than
frame relay and existing LAN protocols, which all use variable length
packets, for carrying real-time data and multimedia applications.
Second, ATM\'s short packet format enables the cells to be formed and
routed almost entirely in hardware. This hardware capability is likely
to allow far faster network speeds than are possible with today\'s
multiprotocol routers, which rely on software to handle the bulk of the
switching task. More importantly, ATM\'s speed is scalable up to many
gigabits/s \[2\]. The resulting bandwidth is available from each station
to a server or another station, which provides a big advantage over the
shared bandwidth technology in Token Ring, Ethernet and FDDI.
"Asynchronous" in ATM comes from the fact that cells headed to a
destination appear at varying intervals. Therefore, it is allowed to
perform asynchronous operations between the sender clock and the
receiver clock. The difference between the clocks can be solved by using
empty cells that do not contain useful information.

When an ATM connection is established, the sender's information is
segmented into 53-byte cells and transmitted through the network. The
receiver then reassembles the cells into the original format. The 5-byte
header carries information about the Virtual Channel (VC) and Virtual
Path (VP) in use, the payload type, and prioritizes cell loss. A VP is a
group of VCs. The channels and paths are referred to as virtual because
many channels and paths can be established simultaneously in the
network. A VC carries information of application specific services. The
VP aggregates VCs destined to the same destination to properly allocate
transmission resources. The flexibility and reliability of the network
can be improved by dynamically modifying VP/VC capacity and routing.

The ATM Adaptation Layer (AAL) inserts payload data into the 48-byte
information field of the ATM cell. The AAL provides the flexibility to
carry different types of services with the same format. The network's
task is to use the information in the packet's header to route the cell
from one point to another. With some AAL types, up to four bytes of the
payload type may be used by the adaptation process itself, leaving 44
bytes for the user data.

### ATM Performance Characteristics

Neither error protection or flow control is provided on a link by link
basis in an ATM network. The links in ATM networks have a very high
quality, or low Bit Error Rate (BER). The omission of error correction
protocol improves data transmission efficiency. In addition, ATM
operates in a connection-oriented mode, which allows the network to
guarantee a minimal cell loss ratio, and therefore provide maximum
quality. As a result, the flow control that is used frequently in other
computer networks is not needed for ATM. At call set-up, if enough
resources in the network are available, the connection is then
initialized. When the connection is established, the probability of
overflowing the network is very small, less than 10^-8^ \[3\].

Delay issues in time transparency are mainly applicable to real time
services such as the MMHIS. Other computer data transmissions are not
particularly sensitive to delays, such as CAD file transmission. In
addition, due to the lack of error correction protocols in ATM, three
sources of error determine the overall BER in an ATM network: (1) error
in the information field in the ATM cell, (2) error in the header field
in the ATM cell and, (3) queuing overflow resulting in loss of cell in
the switch.

In a Local Area Network (LAN) based ATM environment, the delay times
include (1) the distance dependent Transmission Delay (TD), (2)
Packetization Delay (PD) at the sender end, (3) Depacketization Delay
(DD) at the receiver end, and (4) Switching Delay (SD). The size of ATM
cell affects the overall network delay, the transmission efficiency, and
the implementation complexity. It is shown \[3\] that when the size of
the ATM cell (packet) is fixed to 53 bytes, the total delay is limited,
which is an advantage for real time services.

### Quality of Service (QOS)

Properly implemented ATM networks solve the major problems of existing
popular networks in the two areas of high speed interfaces and
multimedia support with video, voice, and data in one transfer. Constant
Bit Rate (CBR) and Variable Bit Rate (VBR) are typically for the
transmission of voice and video respectively. Unspecified Bit Rate (UBR)
and Available Bit Rate (ABR) can be used for regular data traffic. Each
traffic type requires a different quality of service (QOS) with
properties such as the amount of bandwidth reserved, delay tolerance,
and variation.

QOS of a connection is a general indicator relating to cell loss, delay,
and delay variation incurred by the cells belonging to that connection
in an ATM network. It represents user perception of service quality at
the receiving end of the network. It is a function of terminal
capability (bit rate) and network performance such as cell-loss ratio
and bit errors in a cell payload \[4\]. The bit rate ranges from
videophone at a very low rate of 64 Kb/s (Kilobits per second) to High
Definition Television at over 20 Mb/s. The bandwidth management, key to
the support of multiple services on ATM, guarantees QOS for high
priority, delay sensitive CBR and VBR traffic, while providing bursty
UBR and ABR traffic with fair access to the remaining network bandwidth.
For example, ATM switching ensures the integrity of CBR and VBR
connections through connection admission control algorithms. Flow
control and intelligent buffering are used in the ATM switch to optimize
the bandwidth available for data traffic (UBR and ABR). Flow control
detects congestion in the network and informs the sending device to slow
down.

### Gigabit Local Area Networking for MMHIS

In an MMHIS, a number of computers connected through a network medium
are used to transmit and receive high quality video streams and regular
engineering databases. The MMHIS needs to be scalable to accommodate the
data rate of future digital television standards. For instance, one
uncompressed High Definition Television (HDTV) stream carries a data
rate of over one Gb/s (gigabit per second). The compression ratio for an
HDTV signal can be from 20:1 to 50:1. Based on a study by Kinoshita et
al. \[5\], the peak rate can be 65Mb/s and an average 10 to 20 Mb/s for
one HDTV stream transmission in an ATM network. Based on communications
with a State Highway Agency (SHA), the possible number of simultaneous
users accessing video and data streams can be as high as 50. Therefore,
the aggregated data rate in an MMHIS network will well exceed one Gb/s
when HDTV level video streams are used.

A gigabit LAN is a LAN for which the physical communication medium has a
peak bandwidth on the order of one Gb/s or higher, and for which an end
user is able to realize this gigabit performance \[6\]. Clearly, an
MMHIS based network will be a gigabit LAN. In high speed networks, the
specification for transmission protocols follows the SONET (Synchronous
Optical Network) standards based on the base signal rate of 51.84 Mb/s,
which is commonly referred to as OC-1. The higher speeds are OC-3,
OC-12, OC-24, and OC-48 with the speeds of 155.52 Mb/s, 622 Mb/s, 1.244
Gb/s and 2.488 Gb/s respectively. ATM adapter cards at OC-3 speed are
widely available. Many LAN based ATM switches have aggregated data rate
at or over the OC-48 specification.

## The Video and Storage Server

Transmission of multiple digital video streams requires very high
consistent data throughput for every sub-system in the MMHIS that
processes the streams. The sub-systems include the desktop CPU's, bus
and display cards, the networking devices (adapters and switch), and the
video server and storage mediums. Special attention needs to be focused
on the capabilities of the video server and the video storage. For
example, a traditional uniprocessor based server is not able to handle
multiple video streams. Virtually all video servers are based on the
powerful symmetrical multiprocessing structure with multiple
microprocessors. Multimedia also requires huge amounts of data storage
and a very high sustained data rate. Storage size and sustainable speed
are two critical factors for the implementation of a storage server for
the MMHIS.

### Issues Related to Multimedia Oriented Network Operating Systems

In a multimedia application, it is required that large blocks of digital
video/audio data be transferred simultaneously and continuously in order
to ensure the high degree of consistency in picture frame and
synchronization with audio or other data. The dominant network operating
systems used today do not have the capability to coordinate video data
flow sufficiently to ensure video quality on the clients' desktops. The
current network management software emphasizes data integrity through
error control protocols. Therefore, it is imperative to ensure that
video/audio data steams flow at consistent latency in the network and no
traffic clogs for video/audio data occur. It should be noted that even
though many ATM standards have been set, some important standards
regarding QOS and MPEG2 video transmission are not ready yet.

Protocols are software layers in the network, which ensure that data
arrives without errors, and traffic flows are regulated properly. For
video/audio data, a special video protocol is necessary to make sure
there is a highly reliable connection for an uninterrupted stream of
data. The flow of regular data can be conducted through the normal
protocols. With this parallel protocol approach, video/audio data will
have priority over other data flows. Normal data flows yield right of
way to video/audio data. The challenge in developing a continuous-media
software solution for video lies in the management of a large number of
data streams leaving the server. A critical technique in developing such
a solution is through the use of a set of ATM specific Application
Programming Interfaces (APIs). The new WinSock 2 specification that
includes ATM APIs as standard features will be used in the development
of the MMHIS.

### Requirements for the Multimedia Storage Server

The MMHIS consists of client stations, one or more storage systems, a
high-speed ATM network, real-time-service oriented operating systems and
customized applications. The client stations are able to receive very
fast ATM cells, repacketize them, and decode the video data and display
the motion video to the computer screen with synchronized engineering
data sets. The storage system should be able to simultaneously process
multiple requests for video and data streams and send the requested data
fast enough to the clients through the ATM network.

There are four fundamental characteristics of the storage server for
MMHIS:

-   *Real-time storage and retrieval of continuous video media.*

-   *Large data transfer rate and huge storage space requirement.*

-   *Dynamic synchronization with and display of traditional engineering
    data sets with the video frames.*

-   *Multiple simultaneous accesses to the video and data files.*

The storage requirement of video footage at MPEG2 quality (average 5
Mb/s) is about 222 GB for a 5,000-lane-mile interstate system when the
video is recorded at the speed of 50 miles per hour. This huge storage
needs to be randomly accessed by multiple users at any point of the
video footage.

Continuous playback of a video stream consists of a sequence of
retrieving video blocks from server disks with scheduled play time. It
is possible to fetch the video stream from the server fast enough to be
played back at the client station. However, the bursty nature of data
retrieval from disks does not guarantee continuous operation of the
video display. Quite possibly, there will be disruptions of the display
due to inadequate video data. Therefore, a buffer storage needs to be
used at the client station or the server to contain the video stream
before it is played as shown in Figure 8. Buffering is both expensive
and time-consuming. The goal is to design a system that would prevent
client starvation for video data and at the same time minimizing buffer
space and initialization latency. Employing modest amount of buffering
enables conventional file and operating systems to support continuous
storage and retrieval of isolated video streams.

[]{#__RefHeading___Toc417708333 .anchor}Figure 8 -- Buffering Scheme for
Video Stream Playback

The multimedia storage server has to process requests from several
clients simultaneously. More often than not, different clients may
request to view different locations of the highway video footage.

### File System for the Server

The following factors need to be considered for the server storage:

-   *simple, hierarchical directory structure,*

-   *efficient use of low-cost, high capacity disk drives,*

-   *efficient handling of both large and small file system objects,
    and*

-   *optimization for random access, rather than sequential access.*

In addition, it is not necessary nor possible to optimize access based
on a drive's physical geometry. It is not possible to even determine the
real drive geometry at all: track and sector sparing, automatic sector
reassignment, etc. The actual disk layout is completely hidden from the
user and optimized for large sequential accesses. Most new drives have
large data buffers and perform read-ahead and write-behind operations.
The best way to get optimum performance is to stream large amounts of
sequential data similar to a traditional tape drive. Therefore, the
filing system for the video server should be able to:

-   *lay the disk out so that objects are in large, sequential chunks,*

-   *allocate I/O buffers so that transactions are as large as possible,
    and*

-   *minimize the amount of disk seeking.*

The algorithm to be used is straightforward, assuming all new files are
going to be large, and disk space can then be reserved accordingly.
Therefore, when allocating space for a file, reserve a large contiguous
chunk at the beginning, and then use up the reservation as needed. As a
video file grows, extra contiguous chunks are reserved. When the file is
closed, the unused space is freed. In MMHIS, one large video file can be
used to cover a few hundreds of miles of roadway. This file may need to
be updated only annually. Therefore, this filing system is applicable
for MMHIS. In addition, only read operations are allowed on video files
in an MMHIS system, which simplifies the optimization of the file
structure due to the infrequent write operations. Although this
algorithm may cause the fragmentation of disk space, as the contiguous
files are very large with the sizes of multiple gigabytes, the side
effect of spare blocks can be minimized through an efficient managing
algorithm.

In the task of optimization for sequential access, it is realized that
in an MMHIS system, the accesses to video files are read-only operations
and sequential in nature. However, the initialization of viewing request
is random in nature. For instance, multiple users may request to view
any section of the roadway at the same time.

It should be noted that cache strategies used frequently to improve
storage performance do not apply to video files. Video files used in
MMHIS are gigabytes in size. The application of a cache can only add
overhead to a disk streaming operation, and the size of any type of
cache is much smaller than a typical video file in MMHIS.

### Disk Arrays for the Server Storage

The sustained bandwidth of a single hard drive can be as high as 10 MB/s
for sequential access. However, when multiple users access the video
file(s) in a single drive, the available bandwidth for individual user's
video stream is much less than the average theoretical rate, for
example, 10 MB/s divided by the number of users. The overhead is due to
head seeking time and disk management. Therefore, the structure of
putting a number of drives to a Small Computer System Interface (SCSI)
channel will not be able to adequately serve multiple users.

A technology called Redundant Arrays of Inexpensive Disks (RAID) is
widely used to overcome the inherent throughput limitations of a single
disk drive. Various RAID configurations are designed to address either
performance or reliability. RAID comes in several flavors from levels
zero through five. Each level is optimized for various capabilities,
including improved performance of read and write operations, and
improved data availability through redundant copies or parity checking.

The computer industry\'s experience with SCSI has brought to light the
need for improvements of versatility and throughput. For instance, even
in a RAID and SCSI-2 based system, the storage's maximum sustainable
rate is about 20 Mb/s. New applications, like video and image
processing, have created a demand for huge increases in storage
capacity. Some capacity requirements are so large that it is difficult
to configure enough SCSI buses to make sufficient drive addresses
available to attach the needed number of drives.

One solution is a relatively new technology called Fiber Channel, which
is a standard interface adopted by the American National Standards
Institute. The existing implementation of Fiber Channel is called Fiber
Channel - Arbitrated Loop (FC-AL). FC-AL is used as a direct disk
attachment interface for I/O performance-intensive systems. SCSI-3
(Small Computer Systems Interface-3) has been defined as the disk
protocol, which is also technically referred to as the SCSI-FCP.

The Fiber Channel interface is a loop architecture as opposed to being a
bus - like standard SCSI-2. The Fiber Channel loop can have any
combination of hosts and discs up to a maximum of 126 devices and
provide 100 MB/s of bandwidth. The maximum cable distance can be as long
as 10 kilometers. In addition, FC is a generic, standard interface,
supporting many protocols, such as SCSI, Internet Protocol, and ATM. The
loop structure enables the rapid exchange of data from device to device.
Devices can be removed or inserted without disrupting the operation of
the loop. The drives attach directly to the backplane for both signal
and power. Neither jumpers nor switches need be set on the drive. The
controller determines a drive\'s address from either the relative
position on the backplane or the drives unique IEEE Fiber Channel
address.

## MMHIS Development

The test data for the MMHIS was collected in a van as shown in Figure 9,
which uses Super-VHS or a similar quality system for video recording.
The source video is then sent to the compression system for MPEG
encoding. Figure 9 also illustrates the multimedia data flow within a
state highway department. ATM networking technology is used in MMHIS to
link the client stations, the production station, the server and the
encoding system.

![](media/image7.wmf)

[]{#__RefHeading___Toc417708334 .anchor}Figure 9 -- Video Data Flow In
The MMHIS For A State Highway Department

A motion JPEG comparable video stream in MPEG format is normally
referred to as a type of high quality MPEG specification known as MPEG2
of Main Profile at Main Level. A combination of profile and level
determines the frame rate and size. For example, MPEG2 of Main Profile
at High Level Type 1 is to be used for US HDTV with the resolution of
1,152 lines/frame, 1920 pixels/line and 30 frames per second \[7\]. The
current mainstream MPEG2 is Main Profile at Main Level with the
resolution of 720 by 480. It is determined that in order to provide
useful video information for highway engineering work, high quality
digital video for the MMHIS is required. Either MPEG2 or Motion JPEG can
provide Super-VHS or higher quality that meets the quality requirement.
Even though motion JPEG based CODEC's provide very high quality video,
it requires over 5 times more data throughput than a comparable quality
MPEG video stream. Therefore, MPEG2 of Main Profile at Main Level is to
be used in the actual development of the MMHIS.

### The Hardware Structure for the MMHIS

-   Client and Server.

Based on current practices of highway agencies and fast growing
capabilities of Intel x86 processors and related I/O sub-systems, the
hardware platforms for both the video server and clients are going to be
Pentium or better computers. The video server is symmetrically based
with four or more state-of-the-art Intel processors to distribute the
management of data streams among processors. The computer bus is based
on PCI with a peak I/O bandwidth of 132 MB/s.

-   Storage.

The storage requirement of video footage at MPEG2 quality (average 5
Mb/s) is about 222 GB for a typical 5,000-lane-mile interstate system
when the video is recorded at the speed of 50 miles per hour. The
sustained throughput for the video storage is one of the critical
elements in the MMHIS to ensure timely delivery of multiple video
streams to the desktop computers. Fiber Channel and RAID-3 will be used
as the server storage technology.

-   ATM based networking devices.

This includes adapter cards for each computer and switch(es). OC-3 based
155Mb/s cards and a 2.5Gb/s ATM switch are used in the development.

-   MPEG2 encoder

One MPEG2 encoder of Main Profile at Main Level is necessary for
development. Only one encoder is needed for a production level MMHIS. An
MPEG2 decoder and video card is used for each client station. Many
vendors have developed combo PCI based video cards that overlay MPEG
quality motion video on the computer screen. New MPEG2 based combo video
cards will be used in this MMHIS, which allow us to overlay MPEG2 video
on the computer screen of a client station.

# Operation of MMHIS

## Starting up the System

MMHIS is started by double-clicking the icon of the MMHISMain.EXE file.
The opening screen is similar to the screen shown in Figure 10.

![](media/image8.jpeg){width="4.9in" height="3.592361111111111in"}

[]{#__RefHeading___Toc417708335 .anchor}Figure 10 -- Startup Screen of
MMHIS

## Starting a New Query

A main application of the MMHIS is to examine the right-of-way view
along with site-accurate location data. The user can start up a query by
giving input data on the location of the site: choose *New* from the
*File* menu to open the *MMHIS Query Location* dialog box shown in
Figure 11.

![](media/image9.jpeg){width="3.0395833333333333in"
height="1.2270833333333333in"}

[]{#__RefHeading___Toc417708336 .anchor}Figure 11 -- The Query Location
Dialog Box

The user is required to choose state, route number and direction of the
highway that is going to be queried, and the year number from the above
dialog box. The starting milepost number needs to be input in the above
dialog box. Note that the default unit of the milepost number is
kilometer. The unit can be changed to mile by clicking on the button
shown in the dialog box. After the above information is entered into the
dialog box, click *OK* to begin running the query. Please note that
MMHIS dynamically loads database information into the system. For
instance, when the route number and direction is selected, the available
years in the next list box are displayed immediately. When the year
number is chosen, the distance range of the particular highway is
immediately shown in the third entry. For more information on how to
manipulate a query, see the sub-section *Running a query*.

## Opening an Existing Query

Queries can be saved into MMHIS query files. When saving a query, the
query state, route number, direction, milepost, unit setting, data
update rate, window management settings, windows' layout, site data
format, font setting, and graphing window zooming factor are all stored
to a disk file. The next time MMHIS is run, the user can simply open the
saved query and continue doing work on that query. There are two ways to
open an existing query. One is to choose the file from the *Most
Recently Used File* list on the *File* menu. The other is to choose
*Open* from the *File* menu to activate the *Open* dialog box shown
Figure 12.

![](media/image10.jpeg){width="2.8993055555555554in"
height="1.7944444444444445in"}

[]{#__RefHeading___Toc417708337 .anchor}Figure 12 -- The File Open
Dialog Box

The default extension for the query files is .HIS (meaning Highway
Information System). To keep every file organized, it is recommended
that all query files be put into a common directory, e.g.,
C:\\MMHIS\\QUERY.

## Running a Query

After an existing query is opened or a new query is started, the system
is ready to run the query. The application window will look similar to
the one shown in Figure 13.

![](media/image11.jpeg){width="4.9in" height="3.592361111111111in"}

[]{#__RefHeading___Toc417708338 .anchor}Figure 13 -- An Open Query in
MMHIS

The highway video is shown at the bottom-right corner of the frame
window while the corresponding site data are shown at the bottom-left
corner of the window. Two graphing windows are shown at the top-right
corner of the frame window. This will be further explained in the
sub-section *Dynamic Graphing*. The 3D-map window is shown at the
top-left corner of the frame window. The following operations can be
conducted on the query.

-   Running the video

The button with a small arrow on it on the bottom-left corner of the
video window can be used to play and stop the video. While the video is
playing, data in the site data window will change accordingly. The
video's play speed, the video window's size, and many other factors can
also be configured through a context menu offered by the video window.

-   Dragging the video to a new location of the highway

This can be achieved by using the mouse to drag the little slider on the
slider bar on the bottom of the video window.

-   Specifying a new location

A new location can be specified by choosing *Specify Location* from the
*Tools* menu. The sub-routine that this menu item activates is the same
one used to make a new query. It is shown in Figure 11.

-   Changing the font for the site data window

This is achieved by choosing *Choose Font\...* from the *Options* menu.
The dialog box shown in Figure 14, which is activated by the above menu
item, allows users to choose a new font. Note that a context menu is
also offered to the site data window. The *Choose Font\...* option is
also on the context menu.

![](media/image12.jpeg){width="2.7493055555555554in"
height="2.3673611111111112in"}

[]{#__RefHeading___Toc417708339 .anchor}Figure 14 -- Font Selection
Dialog Box

-   Changing the unit for the site data display

The unit used in the site data display in a new query defaults to the
Metrics system. It can be changed by choosing *Units* from the *Options*
menu. This is shown in Figure 15.

![](media/image13.jpeg){width="2.8895833333333334in"
height="1.1916666666666667in"}

[]{#__RefHeading___Toc417708340 .anchor}Figure 15 -- Changing the Unit
Through Menu Selection

-   Changing the data update rate for site data table.

The fastest data update rate is every 25 meters. The actual displaying
rate and quality of video motion is limited by the machine speed and the
distance spacing among adjacent records in the database. Currently the
AHTD database contains records for every 25 meters. To change the data
update rate, choose *Site Data Update Rate* from the *Options* menu, as
shown Figure 16. The option is also offered in the context menu.

![](media/image14.jpeg){width="2.939583333333333in"
height="1.5604166666666666in"}

[]{#__RefHeading___Toc417708341 .anchor}Figure 16 -- Changing the Site
Data Update Rate

-   Opening another query

The current hardware speed does not allow the system to run more than
one query (open multiple video/site-data-table) simultaneously at a good
quality level. However, the user can still open multiple video windows
simultaneously. Windows of each query can be resized and re-positioned
so that they can be seen simultaneously on the screen. The system allows
the running of one query's video while all the other queries' videos are
frozen (i.e. the videos are paused). This is shown in Figure 17.

-   Making turns

The system allows users to choose which way to proceed at intersections
or exit ramps. When the vehicle approaches an intersection or an exit
ramp, the highway video pauses and MMHIS displays arrows to show
possible turning movements, as shown in Figure 18. Users can click on
one of the arrows to make turns. If none of the arrows is clicked for a
certain time (configurable by the user), the system will take the
default option (normally the *Through* allow) and continue to play the
video.

-   Change the site data display format

The site data display format can be changed through the context menu for
the site data window. Two formats are offered for the display. One is
called categorized format, which is the default. This format shows the
site data grouped by categories. The groups can be expanded and
collapsed by double clicking on the category name. When a group is
collapsed, it is shown in a single line with *\<Closed\>* as the item
name. Shown in Figure 19 is the case with "Layer Info" and "Other Info"
groups closed.

The second format is user configurable, where only two columns are shown
in the site data window, shown in Figure 20. The user can configure data
items and the order of the items to be displayed through the use of a
dialog box, shown in Figure 21. In the dialog box, items in the left
list box represents those shown in the site data window. Available items
are listed in the right list box. An item in one list box can be moved
to the other list box by double clicking on it. Items in the list boxes
can also be selected first and then moved to the other list box by
pushing one of the buttons in the middle of the dialog box. The order of
the items in the left list box can be changed with the two buttons at
the left of the list box. Default settings can be restored with the
*Default* button. The dialog box shown in Figure 21 is invoked by using
the site data window context menu.

![](media/image15.jpeg){width="4.548611111111111in"
height="4.6819444444444445in"}

[]{#__RefHeading___Toc417708342 .anchor}Figure 17 -- Two Queries

![](media/image16.jpeg){width="4.489583333333333in" height="3.35in"}

[]{#__RefHeading___Toc417708343 .anchor}Figure 18 -- Making Turns

![](media/image17.jpeg){width="1.9006944444444445in"
height="2.6534722222222222in"}

[]{#__RefHeading___Toc417708344 .anchor}Figure 19 -- Categorized Site
Data Format

![](media/image18.jpeg){width="1.9006944444444445in"
height="2.548611111111111in"}

[]{#__RefHeading___Toc417708345 .anchor}Figure 20 -- User-defined Site
Data Format

![](media/image19.jpeg){width="3.6118055555555557in"
height="2.845138888888889in"}

[]{#__RefHeading___Toc417708346 .anchor}Figure 21 -- Dialog Box Used to
Define Site Data Format

-   Saving a query

To save the query that is currently running, choose *Save* from the
*File* menu. For new queries, this will bring up the *Save As* dialog
box which asks the user to give a name and location for the query to be
saved. For existing queries, the system will save the query without
giving user the opportunity to change the name of the query. To save the
query using a different name, choose *Save As\...* from the *File* menu.
The same dialog box that is mentioned above will show up, as shown in
Figure 22. Refer to the section *Open an existing query* for more
details about what is saved for a query.

![](media/image20.jpeg){width="2.8993055555555554in"
height="1.7944444444444445in"}

[]{#__RefHeading___Toc417708347 .anchor}Figure 22 -- The Save As Dialog

## Dynamic Graphing

An additional capability of dynamic graphing is built into the MMHIS.
The data sets shown in the table by the side of the video do not present
relative information on the whole section of road. This dynamic graphing
capability allows the user to view the values of various attributes,
such as roughness and rutting at this particular location against all
the values in the road section. The real-time location as the video
indicates is shown with a vertical bar on the curves. The ranges that
the graph windows show can be set by choosing *Zoom Roughness Graph* and
*Zoom Rutting Graph* from the *Options* menu. This is shown in Figure
23.

![](media/image21.jpeg){width="3.0493055555555557in"
height="1.7791666666666666in"}

[]{#__RefHeading___Toc417708348 .anchor}Figure 23 -- Changing the
Zooming Range for the Graphs

The vertical bar in the graphing window shows the current vehicle
location. It can be dragged to a new location. This is shown in Figure
24.

![](media/image22.jpeg){width="4.9in" height="3.592361111111111in"}

[]{#__RefHeading___Toc417708349 .anchor}Figure 24 -- The Dragable
Vertical Bar in Graphing Windows

## Using the map

The map interface offers a convenient method to query data through
clicking the right mouse button on a point on the map. A small pop-up
window will show up with the coordinate information of the point. The
road information, if any, will be displayed. Upon the selection of a
menu item, the video will go to that location, while the site data
display will be updated to reflect the new location information, shown
in Figure 25.

![](media/image23.jpeg){width="4.489583333333333in" height="3.35in"}

[]{#__RefHeading___Toc417708350 .anchor}Figure 25 -- Getting Information
from the Map

Zooming and panning operations are offered in the map window. There are
two ways to conduct zooming operations. The first is to conduct a
zooming operation directly on the map through clicking the center point
of the area and dragging the mouse to define the zooming area, shown in
Figure 26.

![](media/image24.jpeg){width="4.49375in" height="3.0in"}

[]{#__RefHeading___Toc417708351 .anchor}Figure 26 -- Directly Zooming on
the Map

The second way is to open the zooming window at the corner of the map
window and zoom through that window. To open the zooming window, simply
click on the *Zoom* button. A resizable rectangle is in the window
illustrating the current zooming area. In addition, two slider bars are
offered in this window so that the user can use them to adjust the
viewing angles. The user can zoom and pan to a specific area by resizing
the rectangle and moving it to the destination. When the *zoom* button
at the bottom of the zooming window is clicked, the map is updated. An
example is shown in Figure 27. The small circle on the road shows the
current vehicle location.

![](media/image25.jpeg){width="4.49375in" height="2.829861111111111in"}

[]{#__RefHeading___Toc417708352 .anchor}Figure 27 -- A Zoomed-in Map
with an Open Zooming Window

## Building the video frame index

The index building interface is used to build frame indices for the
video. With this interface, users first open a video file by specifying
the video file name or by browsing the video files from the disk. The
global ranges can be specified with the controls in the window. In
particular, the start and end frame numbers can be either manually set,
or by moving the slider in the video window to the frame and set the
frame numbers using the buttons in the window. The state, route number
and direction, start and end milepost, and unit can also be chosen. The
index-building module uses the vehicle speed data in the database to
calculate the frame index. If the speed data in the database is
accurate, the above information is enough to calculate the frame index
for the whole video. If the speed data is not quite accurate, key points
can be used to increase the accuracy of the calculation. In addition,
turning points and turning prompts must be set manually because there is
no data in the database showing the turning information. Users define
key points by moving the video to a specific frame and by specifying the
key milepost for that frame. Several search buttons are offered in the
window to help the user find the already defined first key point,
previous key point, next key point, last key point, previous turning
point, and next turning point. Key points can be added or removed by
clicking the *Add Key Point* or *Remove Key Point* button. For a frame
at an intersection or an exit ramp, a turning point is defined by
checking the left turn, through, and/or right turn check boxes and
specifying the destination state, route number and direction, and
milepost. An option is offered to allow the video frames in the video
window to be synchronized with the key mileposts displayed in the
window. When this option is checked and the already defined key points
and turning points are being searched, the video frame display in the
video window is synchronized with the key points. The database is
updated after the *Update Database* button is clicked by the user. The
index building interface is shown in Figure 28.

![](media/image26.jpeg){width="4.819444444444445in"
height="3.533333333333333in"}

[]{#__RefHeading___Toc417708353 .anchor}Figure 28 -- The Index Building
Interface

# Conclusion

To implement the MMHIS in an operational environment, a high performance
network and a powerful video and storage server is necessary. In order
to have simultaneous and instant accesses to the MMHIS data, the
application of new technologies such as ATM or FastEthernet, and RAID is
needed. In addition to the installation of a high performance network
system in the headquarters in a highway department, the distribution of
hard copy videodisks to remote district offices may be a plausible
alternative to building a wide area network. For example, the maximum
capacity of a new kind of CD, the Digital Versatile Disk (DVD), is 18.8
gigabytes, which can hold 400 lane-miles video information at MPEG2
quality. The implementability of an MMHIS needs to satisfy three
factors: (1) maturity of hardware and database technologies, (2)
acceptable implementation costs, and (3) high video quality and
resolution.

We believe that the technologies associated with the implementation of
MMHIS are mature and the costs associated with the implementation are
continuing to come down. The cost-effectiveness of using the MMHIS is
exhibited not only in the form of improvement of office productivity,
but also in the actual cost savings through the reduction of travel for
site inspections. Preliminary highway site inspection normally involves
two people and can take as much time as two or more days. If the number
of such trips can be reduced through the use of the MMHIS, the savings
of travel costs and labor in just one year for a highway department can
be substantial.

As MMHIS is technology-driven, additional features can be built into
MMHIS over time. New features of Geographical Information System and
high-resolution 3-D terrain data will be useful for an integrated
highway management and design. When statewide terrain data in the MMHIS
is updated with Digital Elevation Models (DEM) of sub-meter resolution,
it is possible to conduct preliminary engineering design of cut-and-fill
and planning the development of new transportation systems.

# References

1.  Wang, K.C.P. and Robert P. Elliott. Design Considerations for A
    Distributed Multimedia Based Highway Information System. Presented
    and Published by Transportation Research Board, National Research
    Council, 1995.

2.  Partridge, C., *Gigabit Networking*. Addison-Wesley Publishing Co.,
    Massachusetts, 1994.

3.  Prycker, M.E. *Asynchronous Transfer Mode: Solution for Broadband
    ISDN*, 2nd Edition, Ellis Horwood, New York, 1993.

4.  Yamazaki, K., M. Wada, Y. Takishima, and Y. Wakahara. ATM networking
    and video-coding techniques for QOS control in B-ISDN. *IEEE
    Transactions on circuits and systems for video technology*, Vol. 3,
    No. 3, January 1993, pp. 175-181.

5.  Kinoshita, T., T., Nakahashi, and M. Maruyama. Variable-Bit-Rate
    HDTV CODEC with ATM-Cell-Loss Compensation. *IEEE Transactions on
    Circuits and Systems for Video Technology*, Vol. 3, No. 3, January
    1993, pp. 230-236.

6.  Kung, H.T. Gigabit Local Area Networks: A Systems Perspective.
    *Advances in Local and Metropolitan Area Networks*, edited by
    William Stallings, IEEE Computer Society Press, California, 1994,
    pp. 49 - 59.

7.  Minoli, D. and R. Keinath. *Distributed Multimedia Through Broadband
    Communications.* Artech House, Massachusetts, 1994.