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 9
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 9
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.