Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 9
10
is an example of this--where considerable cost savings are projects are derived from crash reports and traffic data
already being achieved. linked by location.
Other data exchange needs during the construction phase Crash data need to be transferred from the collection point
include support for electronic bidding processes; transfer (e.g., a police report) to processing point(s) (for validation and
of bidding information into contractor payment systems; linkage with other data) and then on to archive point(s). This
transfer of work tracking and payment information between process commonly involves exchange of the data across multi-
central and field offices; transfer of materials testing infor- ple agencies. Once processed, crash reports and linked crash
mation among the construction site, laboratories, and cen- information are shared across a wide variety of audiences (pub-
tral offices; and information sharing about construction lic agencies at state and local levels, interest groups, insurance
project status. companies, etc.). Given consistent key information required
for linking across safety data sets, different types of safety data
can be gathered from their respective sources and joined
2.4 Highway Bridge Structures
together for a variety of reporting and analysis purposes.
This business area spans bridge planning, design and analy- Linkage of transportation safety-related information
sis, construction, inspection, management, operations, and depends to a large extent on location identification. Unfor-
maintenance. Thus, bridge data includes information required tunately, different data sources typically use different location
for initial design of the structure, information about the phys- referencing methods and different roadway system models.
ical design of the structure as a whole and its individual ele- Emerging software standards in these areas may provide a
ments, information about the loads carried by the structure, common understanding and representation scheme for XML
condition and load rating information required for mainte- encoding.
nance and permitting, and information about the function of Transportation safety has a significant real-time component
the structure in the road network. as well, including activities such as roadside inspection of com-
Key data exchange processes in the bridge structures area mercial vehicles, emergency response, incident management,
include transfer of highway geometry parameters from high- driver information, and work zone management to ensure
way design to bridge design; transfer of bridge design infor- safety of road users. These activities rely on exchange of real-
mation to highway engineers; provision of coordinates and time data on traffic, incidents, response status, road conditions,
station information to surveyors; loading of bridge design and weather. These types of data exchange requirements are
inputs (geometry, materials, loading information) to multi- encompassed within the ITS area (see below).
ple design software packages; transfer of design information
(geometry, quantities, digital terrain model information) to
2.6 Broader Framework
estimating systems; transfer of as-built information to inspec-
for TransXML
tion, rating bridge management and maintenance manage-
ment systems; and transfer of bridge design and inspection/ The four business areas selected for initial focus of
condition information to permitting and routing systems. TransXML cover an important, but relatively small portion
Federal reporting of bridge inventory and inspection infor- of the universe of surface transportation data exchange needs.
mation represents another data exchange need. A broader framework for TransXML is illustrated in Figure 1.
The first row in this diagram shows the initial four business
areas; the second row shows potential future business areas.
2.5 Transportation Safety
The final row of the figure shows areas where there are
Transportation safety data includes information about already active XML and standards development efforts that
crashes that occur (where, when, why, who, how), informa- TransXML should link to or coordinate with.
tion about their consequences (emergency medical informa- The broader framework for TransXML includes the fol-
tion, insurance information) and information about the lowing distinct but overlapping viewpoints:
characteristics of facilities, vehicles and drivers that pose
safety risks. This latter set of data includes highway design Geospatial View--Transportation data is fundamentally
and operational characteristics, vehicle registration infor- geographic in nature, and therefore there has been consid-
mation, vehicle inspection information, motor carrier inspec- erable work to date on development of data standards and
tion and driving records, and citations. Raw crash report models focused on the geospatial representation of trans-
data is linked to roadway, vehicle, motor carrier, and driver portation information. These allow for sharing, linking,
information to yield additional information--for example, and integrating a variety of geographic data sets (including
highway crash rates used for analysis of the need for safety those from nontransportation domains). For example, the
OCR for page 10
11
TransXML
Construction/
Survey/Design Bridge Safety
Materials
Asset Maintenance Project Program
Management Management Development Development
Operations/ Modeling/ Geospatial Freight/
ITS Simulation Data Logistics
Figure 1. TransXML current and potential future scope.
Geospatial One-Stop (GOS) data content specification Safety View--This view (to be addressed in the initial
defines a standard representation of data related to road, TransXML effort) is concerned with collection, reporting,
rail, and transit modes. Feature models have also been analysis and use of information needed to reduce transporta-
developed by GIS vendors that can be used to develop geo- tion crashes and fatalities.
databases providing enterprise maintenance of and access
to geographic data in support of multiple applications. The ITS/Operations View--The National ITS Architecture (3)
Open Geospatial consortium (OGC) is supporting contin- represents an important reference model for surface trans-
ued development of Geographic Markup Language (GML), portation processes and data flows. This Architecture defines
which provides an abstract model for representing geo- functions and data flows for real-time operation and man-
graphic information. agement of the surface transportation system. It encompasses
eight different "bundles" of user services: travel and traffic
Infrastructure View--This view is concerned with data management, public transportation management, electronic
exchange within and across different phases of the life cycle payment, commercial vehicle operations, emergency man-
of planning, designing, constructing and maintaining trans- agement, advanced vehicle safety systems, information man-
portation infrastructure. It incorporates planning, engineering/ agement (including archiving real time data for use in other
design, and business perspectives and is the primary focus applications), and maintenance and construction manage-
of the initial TransXML effort. However, this view goes ment. As data interoperability is a key objective of the ITS
beyond the four selected business areas, extending to activ- architecture effort, there are a number of active ongoing ITS
ities including planning and project development (environ- data standards efforts, including NTCIP (National Trans-
mental assessments, permits, right-of-way, etc.), program portation Communications for ITS Protocol), CVISN
development/budgeting, asset management (inventory, inspec- (Commercial Vehicle Information Systems and Networks),
tion, performance monitoring, life-cycle cost modeling, selec- Archived Data, Incident Management, Traffic Management,
tion and prioritization of treatments), and maintenance ATIS (Advanced Traveler Information Systems), and TCIP
management (identifying, scheduling and managing main- (Transit Communications Interface Profile). XML data for-
tenance activities). A recent TRB paper (1) proposed a mats have or are being developed for several ITS-related
semantic architecture to represent the highway construc- areas, including motor carrier safety data, transportation
tion domain using an integrated supply chain model, encom- management center to center communications and traveler
passing planning, design, field construction, and maintenance. information exchange.
Elements of ebXML (2) are used for electronic business
transactions related to highway construction. This paper Travel and Traffic Modeling and Simulation View--This
can be revisited at a later date as TransXML's scope is view is concerned with exchange of data inputs and outputs
broadened. of transportation modeling and simulation tools--including
OCR for page 11
12
socioeconomic data, traveler characteristics, network repre- developing a data dictionary to support new microsimulation
sentations, and network characteristics (travel times and algorithms being developed under that project.
costs). The Traffic Software Data Dictionary (TSDD) pro-
vides an example of data exchange needs from the traffic Freight Logistics View--This view is concerned with the
modeling point of view. A recent paper (4) reported develop- intermodal freight supply chain--sharing of information on
ment of TrafficXML to support exchange of data between shipment and equipment status and location. The TransXML
simulation programs of different vendors. FHWA's Next developed by Transentric covers this area; the standard is now
Generation Simulation Models (NGSIMS) effort is currently being extended by the Open Applications Group.
