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 28
29
tractors to submit information on the work being performed plexity also means that taking on the task of developing XML
by subcontractors. schema for all bridge types is beyond the scope of the current
The information being exchanged includes contract descrip- project. There will be a need to clearly define a manageable
tive information and pay items with quantities provided by the subset of structure types to focus on. In order to make this
agency, and subcontractor descriptive information and pay effort most productive, it is desirable to build upon existing
item subcontracting information provided by the contractor. work that has been accomplished within the AASHTOWare
program on Virtis/Opis, and on prior NCHRP studies that
have addressed bridge specification.
4.4 Highway Bridge Structures
The AASHTOWare Virtis/Opis Project provides a com-
The topic areas for bridge structures included in Table 1 prehensive bridge domain which contains bridge descrip-
spanned the full life cycle of a bridge--analysis and design, tions for the purpose of structural analysis for many bridge
construction, inspection and load rating, management, oper- types. These types include steel plate girder, rolled beam and
ations, and maintenance. Given the common data exchanges built-up multigirder superstructures, reinforced concrete
that occur within and across these areas, three specific busi- tee-beam and slab superstructures, sawn timber multibeam
ness processes within these areas were identified as good can- superstructures and precast, prestressed concrete I-beam and
didates for XML schema: box-beam superstructures. Currently the Virtis/Opis soft-
ware provides a reporting tool that produces an XML repre-
· Bridge Analysis and Design; sentation of the bridge domain. This XML information is
· Truck Permitting and Routing; and used with a dynamic XSL template generator to produce
· National Bridge Inventory (NBI) Reporting/Data Exchange. user-defined reports for viewing using an Internet browser.
The NCHRP Project 12-50 process provides a start for the
Each of these candidates is discussed below. definition of Bridge Specifications information. This process
is currently being applied in research on several NCHRP
bridge-related projects.
Bridge Analysis and Design
The major candidate within the bridge structures area for
Truck Permitting and Routing
inclusion in TransXML is a physical description of the bridge
geometry and structural characteristics. This information is Each state has procedures for issuing permits to vehicles
developed during the structure analysis and design phase, and which exceed established size or weight limits for travel on
then it is used throughout the bridge life cycle for develop- state highways. A number of different permitting and routing
ment of load ratings and as input to permit and routing appli- applications are in place to select a permissible route for a
cations (see below). vehicle based on the vehicle's characteristics (length, axle
A standard XML format for describing the structural ele- configuration and weight) and the characteristics of the road
ments of a bridge would facilitate use of multiple design and network--including bridge horizontal and vertical clearances
analysis packages for a given design problem. According to and load ratings. A standard packet of information about
the AASHTO LRFD specification commentary, the verifica- bridge characteristics required for permitting and routing is
tion of computational processes used for bridge analysis is the a logical candidate for an XML schema.
responsibility of the engineer. Because of the large amount of
specification checking required for a single structure, verifica-
NBI Reporting/Data Exchange
tion of a process is not always simple. Hand checks are not
always practical because of the iterative nature of many of The Recording and Coding Guide for the Structure Inven-
the specification checks. Passing information, both bridge tory and Appraisal of the Nation's Bridges defines a standard
description (input) and analysis/specification results (output), data structure for required annual NBI reporting on all pub-
is often desirable to expedite the comparison of two processes. lic highway bridges. The current reporting format is a fixed
In addition to having a standard description of the bridge format text file. NBI data is produced by bridge management
for input to design and analysis software, it would also be systems (including AASHTO's Pontis system) and many state
useful to have a standard format for representing outputs of DOTs have developed NBI reporting utilities that work with
a bridge analysis. This would facilitate comparisons of the their bridge databases. NBI data is shared across different
structural analysis results across different bridge software agencies and is used for a variety of analyses.
applications which may have different output formats. Developing an XML schema for NBI data would provide a
The complexity of bridge structure description informa- self-documenting format for NBI data and would provide a
tion makes it a good candidate for XML; however this com- much-needed opportunity to address longstanding problems
