Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
22 4.1 Criteria for Identifying XML Schema Candidates XML Schemas provide the mechanism for exchanging information (data) in order to carry out various transporta- tion business functions. Rather than using a data-centric approach to identify TransXML schema opportunities (e.g., what are all of the things about a bridge that anyone would ever need to know?), the approach taken for this project was to use a process-centric view (e.g., what information about a bridge is required to evaluate load restrictions?). The latter question is more focused, and easier to get agreement on. Not all sets of data that feed transportation business processes are good candidates for XML schema. A good candidate for an XML schema is one which has the potential to save time and money, or facilitate improved access to information by ⢠Allowing information produced in one process to be used in other(s); ⢠Eliminating the need for information to be entered from scratch (e.g., getting information from GIS systems into CAD systems or using information from road designs to control GPS-guided excavation equipment); ⢠Allowing agencies to analyze the same set of data in several different software tools, to easily port data from one tool to a new tool, or to share input data across different agencies which make use of varying toolsets; ⢠Eliminating or reducing the need for agencies to build cus- tom applications and interfaces to connect legacy systems; and/or ⢠Enabling reuse of the same information for multiple pur- poses (e.g., sharing information about a scheduled bridge construction project with the DOT permitting office, main- tenance staff, and traveler information systems). The potential benefits of an XML schema increase as the number of different users of and uses for the same âpacketâ of information increases, and as the complexity and critical- ity of the information increases (since these factors affect the costs of duplicate data and the impact of errors that can result from duplicate data entry processes). The ability of a candidate XML schema to achieve these benefits depends on the likelihood that it will be broadly accepted and put into practice. This in turn depends on the ease of getting consensus on a standard data structure, the business case that can be made for the schema, the incentives and disincentives for adoption across the stakeholder com- munity, and the level of advocacy and assistance that is pro- vided to overcome initial barriers to adoption. Therefore, poor candidates for XML schema have the following characteristics: ⢠There is wide variation in data content across agencies and no mandates or incentives to standardize the data; ⢠Information is shared across a small number of identifiable systems or individuals, mechanisms for data transfer are already in place and functioning well, and it would be costly to retool systems to read/write another format; ⢠The structure of data content is highly dynamic in nature and therefore a schema could be obsolete by the time it is put into practice; ⢠The data content is highly detailed and expression in the verbose XML format would result in performance prob- lems for the intended applications; and/or ⢠The data content is so simple or trivial that it is not worth the effort to pursue XML encoding. With these considerations in mind, candidate business processes for XML schemas were identified within each of the four business areas identified in Table 1. Then, the highest priority candidates were selected based on an assessment of the potential payoff from a technical standpoint, the likeli- hood of adoption from an institutional/business case per- spective, and the level of effort that would be required to S E C T I O N 4 Gaps and Opportunities for TransXML
develop and gain stakeholder agreement given the work that has already been accomplished by the previous efforts identi- fied in Section 3. The selections also took into account the fact that several schema development efforts are ongoing (or planned) within other organizations (e.g., LandXML), and therefore any improvements would need to be pursued in coordination with these other organizations. The priority business processes identified in this section are the basis for the selection of the initial set of schemas that were developed for TransXML. 4.2 Roadway Survey/Design In order to explore schema opportunities in the roadway survey/design business area, the research team drew upon a business process modeling exercise conducted as part of a prior project (conducted by Bentley Systems, Inc. for the Minnesota Department of Transportation [MnDOT]). This project produced a set of data flow diagrams which depict the preliminary and detailed design of roadways and related structures. The diagrams show the design activities (func- tions) performed as well as the data that is exchanged between these functions. The data flow diagrams were reviewed from a TransXML perspective. Each data flow was evaluated to determine if it is an appropriate candidate for a TransXML schema. The following subprocesses emerged as candidates for XML schema: ⢠Sharing of roadway geometric design information (hori- zontal and vertical alignments, pavement section, super- elevation, cross sections, geometrics) across design team members as it evolves throughout the design process; ⢠Utilizing information produced in the design phase as the basis for developing as-built information from the con- struction phase, and then making the as-built information available for use during the maintenance and operation phase; ⢠Sharing of surface models across design, survey and con- struction, including use of this information for automated machine control; ⢠Transferring pay item information in the design phase for further development in the construction phase; and ⢠Transferring GIS-based planning information on area fea- tures into CAD-based design software. These subprocesses cover all of the specific topic areas listed in Table 1 under the Roadway Survey/Design business area, with the exception of Pavement Design and Traffic and ITS Design (Right-of-Way may be partially addressed by LandXML, and the GIS-into-CAD area). These two topic areas are fairly large in scope, and involve distinct stake- holder communities (pavement designers and traffic engi- neers), and should be addressed once the initial set of schemas are established. The first three subprocesses have been addressed by the LandXML schema. The following discussion identifies gaps in the existing schema that were considered within the scope of TransXML (in coordination with LandXML.org). Geometric Design/Surface Model Information (LandXML) The most significant information exchanged during design and carried forward into subsequent life-cycle phases is the geometric design of the roadway. Beginning with preliminary design, the roadway design evolves through the refinement of the horizontal and vertical alignments and the addition of pavement section, superelevation, cross sections, and geo- metrics. This is an iterative process based upon project con- straints, codes and other regulations, budget, and time. It is done in conjunction with other disciplines which impact or are impacted by the design, including but not limited to right- of-way, drainage, utility, hydraulic, traffic, environmental, and aesthetic concerns. XML can provide a method of shar- ing the roadway design as it evolves during the design process. It can also provide the basis for capturing as-built informa- tion as the roadway is actually constructed. This information can then be utilized during the maintenance and operation of the roadway. As each member of the design team develops a design solu- tion for their particular part of a project (drainage, roadway, bridge, traffic), they are dependent upon and have influence upon the designers of the other parts of the project. For example, a roadway designer begins with a rough alignment from the preliminary design phase. As this alignment is refined, the results need to be communicated with the hydraulics engi- neer to complete the site drainage; with the bridge engineer to develop the detailed bridge geometry; with the traffic engi- neer to begin staged construction planning; and eventually with the surveyors for stake out (see Figure 2). The information being exchanged which constitutes the roadway design includes the horizontal and vertical alignment, cross sections, superelevation, and geometric information. This area has been a focus for LandXML, which is already in widespread use, supported by LandXML.org and yielding substantial benefits. However, there are areas of LandXML which can be improved: ⢠Provide a semantic model and documentation in order to increase clarity, as certain areas are open for interpretation by users, thereby increasing the usefulness of the schema for interoperability. For one-off data transfers between two specific processes, this interpretation is acceptable as long 23
as the two processes make the same assumptions. As the use of the schema broadens (e.g., extending into construc- tion and maintenance and operation), the ambiguities can become more problematic. ⢠Support the feature-based approach of most spatial stan- dards, including the ISO TC211 191xx geospatial stan- dards, OGC specifications including GML, and Geospatial One-Stop. LandXML supports the CAD notion that geo- metric representation is paramount and that attributes or feature properties can be hung off of these, almost as an afterthought. An enterprise view would be better served by an object or feature-based approach, where the geometric representation is merely one more attribute of a feature. This would accommodate multiple geometric representa- tions for the same road feature, such as a 1:24,000 scale GIS linestring approximation and a 1â³=50â² engineering true curve representation. ⢠Expand to include general purpose topological primitive constructs, i.e., link-node linear networks. Currently LandXML supports linear topology with feature to feature relationships between pipes and structures. TransXML needs to support other linear networks, such as the road- way network itself. ⢠Provide additional enhancements (e.g., the ability to break by lane for superelevation, the need to transition super- elevation nonlinearly, and the featurization at individual points of cross sections). As noted above, because LandXML is already widely used, and there is an established mechanism for improving this schema, the NCHRP 20-64 project did not pursue the above improvements independently from LandXML.org. Rather, NCHRP 20-64 provided a mechanism for developing techni- cal content for proposed improvements that were submitted to LandXML.org for consideration. Contract Pay Items Contract pay items span the design and construction busi- ness areas. Pay items are the basis for estimating the cost of the project, comparing alternative design solutions, obtain- ing a contractor to construct the roadway, assessing the progress of the construction, providing the basis for partial (progress) payments during construction, billing the work completed, and potentially feeding maintenance and oper- ation systems such as roadway inventory and asset man- agement. Though contract pay items predominate in the construction phase, they begin during design and are there- fore proposed as a design business area schema which can evolve into a construction schema as more information is added to the pay items. Pay items provide the basis for estimating, bidding, and construction management. The design engineer determines what pay items make up the project and determines how much of each pay item will be required to complete the job. This is based on a standard set of contract pay items with pre- defined units of measurement. The pay items and their quan- tities are then passed to the estimator to predict the cost of the project. Often the items and quantities are included in the contract documents for the project (see Figure 3). The information being exchanged includes the standard contract pay items with their units of measure, and the quantities of each that will be used on this project. The 24 Create Detailed Roadway Design Coordinate Detailed Design Roadway Design Roadway Design Roadway Design Roadway Design Create Detailed Bridge Design Create Detailed Drainage Design Create Detailed Design of Other Structures Create Detailed Traffic System Design Roadway Design Figure 2. Data flow diagram: coordinate detailed design.
aecXML infrastructure effort produced a good first cut at such a schema, which has been implemented in product at the MnDOT. However, this schema does not completely meet the needs presented here because it doesnât address quantities or prices. A schema that provides a single, con- sistent list of pay items on a project, with quantities and prices would better support the needs of the designer, esti- mator, plans developer, contract administrator, contractor, and inspector. The design-to-construction process emerged as a high- priority candidate for TransXML. The model and resultant XML schema developed here were further augmented within the construction business area in support of pay item data exchange for construction phase activities. The aecXML infrastructure break out was done under the IAI aecXML Domain Committee umbrella, but it was largely an independent effort by the aecXML Infrastructure Working Group. While the IAI aecXML effort is still active, the aecXML Infrastructure Working Group is now dor- mant. Given that the focus of the larger aecXML effort has been on buildings which have substantially different requirements than roadway projects, it was appropriate for NCHRP 20-64 to take on further enhancements to this schema. Area Feature Support Instead of starting with a clean sheet of paper, it would be advantageous if designers could capitalize on the information collected during the planning phase. Much of this informa- tion is available with GIS software which is often incompati- ble with engineering design software. A significant number of data flows involve polygonal data, including environmental areas, soils, wetlands, land use, flood plains, site improvement areas, right-of-way, and cadastral information. Though less significant than the previous two schema opportunities, it does represent a significant gap in the design area. It also is exemplary of the gap between GIS and CAD, wherein traditional systems of each type have pro- vided significant frustration for users in their inability to exchange data. It also is an opportunity for incorporating the common geometry model adopted by the three leading inter- national GIS standards. An example of a design activity requiring such a data exchange is creating preliminary design (see Figure 4). LandXML does support a survey view of a land parcel ele- ment. However, its geometry does not provide support for holes and islands and constraints such as closure, nonover- lapping and nonintersecting rings as specified in other spatial 25 Contract Pay Items Contract Quantities Contract Quantities Legend External Entity Standard Contract Pay Items Determine Quantities Design Pay Items,Quantities Project Design Data StoreBusinessProcessData Flow Create Final Plans Develop Detailed Design Estimate Figure 3. Data flow diagram: determine quantities.
standards. In addition, there is also no support for general purpose area feature geometry usable for other, nonparcel, area features. General polygon support is not necessarily roadway-specific. 4.3 Transportation Construction/Materials Several candidate business processes for XML schemas were identified for the construction/materials business areas in Table 1, i.e., estimates, proposals, letting and award, con- struction management, and materials. These processes are listed below roughly in chronological order based on the life cycle of a construction project: ⢠Acquire reference information for project cost estimates; ⢠Submit project definition of work to oversight institution; ⢠Bid package preparation; ⢠Submit project bid; ⢠Track installed quantities, materials used and tested during construction; ⢠Publish construction status to stakeholders; ⢠Change project scope; ⢠Monitor civil rights, on-the-job training (OJT), labor requirements compliance; and ⢠Monitor subcontract progress. These subprocesses cover the topic areas listed in Table 1 for the Design/Construction business area. Three of these candidates were identified as the highest priority candidates that could be addressed within the scope of the TransXML project: Bid Package Preparation; Track Installed Quantities, Materials Used and Tested During Construction and Publish Construction Status to Stakeholders. These areas were judged to have the greatest potential payoff given the number of dif- ferent users of the information. They also include foundation elements that can be later reused in the other areasâe.g., pay items. The three selected candidates are discussed below, fol- lowed by brief descriptions of the other candidates which could be considered for future extensions to TransXML. Bid Package Preparation Thousands of transportation proposal bid packages are pub- lished each year, often in paper form, to a community of tens of thousands of contractors, subcontractors, and suppliers. A standard transportation Bid Package XML schema would enable agencies to publish bid packages electronically in a stan- dard form that can be directly loaded into bid preparation sys- tems. As a result, information flows will be streamlined, and redundant data entry and the associated opportunity for error will be substantially reduced. Following the creation of pay items in design, a proposal including the pay items is assembled into a bid package that is published to the contracting community. Primary contrac- tors, subcontractors, and suppliers utilize this information to prepare their bids and quotes. The bid package is often pub- lished in paper form, requiring manual loading of the pay items into the tools contractors use to prepare bids. Trans- XML can provide a standard form for publishing the quanti- tative elements of bid package information in electronic form, enabling contractors and suppliers to directly load the information into bid preparation systems. In preparation for letting a proposal, transportation agen- cies publish a proposal bid package. Contractors use this information to prepare their bids. Subcontractors and suppli- 26 Local Authorities FEMA Land Use Flood Plain Information SOILS Information SOILS National Wetlands Inventory Wetlands Information Create Preliminary Design Environmental Constraints, Hazardous Materials, Cultural Locations Right-of-Way ConstraintsRight- of-Way Consultants Figure 4. Data flow diagram: create preliminary design.
ers use this information to identify potential business oppor- tunities and submit quotes to primary contractors. In the event that project changes occur after publication but prior to the letting, the agency publishes these changes in proposal amendments. The bid package contains the following: ⢠Letting location and date; ⢠General proposal information including the project loca- tion, type of work, and vendor qualification requirements; ⢠Contract time information including the completion date and liquidated damages rate; ⢠Pay item information including the item description, quan- tity, and unit of measure; ⢠Design drawings; and ⢠Miscellaneous âboilerplateâ information. Proposal amendments can include changes to any element of this information. Agencies publish bid packages on a monthly or semimonthly basis. With the exception of the graphical information (draw- ings) and boilerplate, the bid package information lends itself well to representation in XML form. The aecXML Infrastructure Project schema already provides some of the general proposal information (project location, type of work, etc.) and pay item information required for a bid package. TransXML can augment the Infrastructure Project schema to support the letting process requirements for pub- lishing bid packages. This can be done by supplementing it with proposal information including the letting location and date, vendor qualification requirements, contract time information, and the additional attributes required for amendments. Track Installed Quantities and Materials Used and Tested During Construction A broad range of field devices are used to measure con- struction progress and track material use, sampling, and test- ing. Various elements of this information are communicated frequently among field, project office, test lab, and central office personnel throughout the construction project. A stan- dard XML schema for this information would enable inte- gration of the diverse data collection and data management systems utilized to track this information, thereby stream- lining information flows and reducing the opportunity for error. TransXML can provide a standard form for communi- cating progress information between systems that utilize the physical project view of items installed and materials sampled and tested and the construction progress payment systems that utilize the business project view. This information lends itself well to representation in XML form. The information being exchanged includes pay item descrip- tive information, partial quantities placed, placement loca- tions, materials samples collected, the field tests performed, and the outcome of those tests. (Note that this candidate process does not address the actual test measurement and process details of the tests that are performed. Developing a consensus on that aspect of materials testing could not be accommodated within the scope of NCHRP 20-64.) Key data flows in the daily project work tracking process are as follows: ⢠At the project construction site, inspectors track partial quantities placed for pay items, project locations where those quantities were placed, the frequency of samples taken for component materials, tests performed and the extent to which the materials meet established specifica- tions. Physical measurements are taken using various types of field equipment. Once collected, this physical view information must be translated into the business view of the project (pay items), and recorded manually or with data collection systems such as handhelds, laptops, or personal computers in the field office. This translation and subsequent entry into the construction progress tracking system or central lab system is typically a man- ual process that has an associated risk of translation and data entry error. ⢠Materials sampling and testing data generally is exchanged between field offices and central laboratories on a daily basis. ⢠The inspectors communicate the progress information to the project engineer, who monitors the overall project status. ⢠On a periodic basis, the project engineer submits a progress estimate to the central office. The progress estimate con- sists of the aggregated partial quantities placed for the pay items and the record of the materials sampling and testing that were performed during that pay period. ⢠The central office processes the progress estimate, trigger- ing a payment through the financial system. The aecXML Infrastructure Project schema provides a good starting point for this TransXML candidateâit already has a pay item complex type that includes the required unique item identifier, description, unit of measure, and one or more associated costs consisting of a quantity, price, and a cost type. This quantity can be a partial quantity placed. The schema also already has a location complex type. However, the following gaps were identified: ⢠Partial quantities placed with a location; ⢠Material samples collected; and ⢠Field tests performed and outcome of those tests. 27
Publish Project Construction Status to Stakeholders External stakeholders such as the general public, elected officials, oversight or regulatory agencies, and other institu- tions such as utilities and railroads require or can benefit from access to timely information about the status of a trans- portation construction project. This information is managed within the agency in their construction management system and is provided to different stakeholders in different forms. TransXML can provide a mechanism for communicating construction project progress information from the agencyâs construction management system to external stakeholders. This information can be presented in a variety of forms appropriate for the individual target audiences. The information being exchanged includes project descrip- tion, location, and fiscal, schedule and progress information, including milestone dates and those affecting traffic. The fre- quency of publication depends on the practices of the agency. The aecXML Infrastructure Project schema provides a ProjectType complex type (imported from the aecXML Com- mon Object Schema) that includes required general project information (project description, location, etc.) and project status information, including current phase, percent complete, begin date, and several completion dates. This schema requires supplementation with additional milestone dates and fiscal and progress information to be useful for status tracking. Acquire Reference Information for Project Cost Estimate Estimators use production, labor, and equipment rates and historical bid and as-built information to estimate labor, equipment, and material costs for the project pay items. An estimator often gets this reference information from a variety of internal and external sources, including data warehouses and commercial and government publications and services. The information being used includes production, labor, and equipment rates, historical bid information, and as-built information. Submit Project Definition of Work to Oversight Institution At various stages in the project life cycle, the transportation agency must submit the definition of project work to various oversight institutions. For example, in the United States, state transportation agencies must submit their construction plans, specifications, and estimates (PS&E) to the Federal Highway Administration (FHWA). When the project is awarded, they must submit the awarded contract to FHWA. Similar require- ments apply for other oversight institutions such as the Army Corps of Engineers, the Coast Guard, and, for international projects, financial institutions such as the World Bank. The information being provided includes project descrip- tive information, pay items with quantities and either esti- mated or contract prices. Depending on the requirements, it may include additional information such as funding sources and projected funding allocations. Submit Project Bid At or before the time of the bid letting, contractors submit their bid for a project to the transportation agency. The bid doc- ument has the bid price for each pay item. Depending on agency requirements, it may include additional information such as subcontracting commitments and bid bond information. The information being submitted includes a bid price for each pay item, and depending on agency requirements, addi- tional information such as subcontracting commitments and bid bond information. Change Project Scope As project construction proceeds, changes to the scope of the project are identified including adjustments to authorized pay item quantities, addition of new work, and changes to contract time requirements. Project staff define the changes to be made and submit them for review and approval. On approval, the changes are communicated to the contractor. The information being exchanged can include contract and project descriptive information, pay item quantity adjustments, new pay items, and modified contract time specifications. Monitor Civil Rights, OJT, and Labor Requirements Compliance Transportation agencies must monitor contractor com- pliance with civil rights, OJT, and labor requirements. Con- tractors may subcontract portions of contract work to other contractors. Agencies require contractors to submit certified contractor payroll information regarding contractorsâ and approved subcontractorsâ workforces. The information being exchanged includes contractor, contract, and employee identifiers, employee characteristics including address, gender, and ethnicity, and daily work infor- mation including hours worked and wage rate information for the pay period. Monitor Subcontract Progress Transportation agencies record progress on both prime contractor and subcontractor work. Agencies require con- 28
tractors to submit information on the work being performed by subcontractors. The information being exchanged includes contract descrip- tive information and pay items with quantities provided by the agency, and subcontractor descriptive information and pay item subcontracting information provided by the contractor. 4.4 Highway Bridge Structures The topic areas for bridge structures included in Table 1 spanned the full life cycle of a bridgeâanalysis and design, construction, inspection and load rating, management, oper- ations, and maintenance. Given the common data exchanges that occur within and across these areas, three specific busi- ness processes within these areas were identified as good can- didates for XML schema: ⢠Bridge Analysis and Design; ⢠Truck Permitting and Routing; and ⢠National Bridge Inventory (NBI) Reporting/Data Exchange. Each of these candidates is discussed below. Bridge Analysis and Design The major candidate within the bridge structures area for inclusion in TransXML is a physical description of the bridge geometry and structural characteristics. This information is developed during the structure analysis and design phase, and then it is used throughout the bridge life cycle for develop- ment of load ratings and as input to permit and routing appli- cations (see below). A standard XML format for describing the structural ele- ments of a bridge would facilitate use of multiple design and analysis packages for a given design problem. According to the AASHTO LRFD specification commentary, the verifica- tion of computational processes used for bridge analysis is the responsibility of the engineer. Because of the large amount of specification checking required for a single structure, verifica- tion of a process is not always simple. Hand checks are not always practical because of the iterative nature of many of the specification checks. Passing information, both bridge description (input) and analysis/specification results (output), is often desirable to expedite the comparison of two processes. In addition to having a standard description of the bridge for input to design and analysis software, it would also be useful to have a standard format for representing outputs of a bridge analysis. This would facilitate comparisons of the structural analysis results across different bridge software applications which may have different output formats. The complexity of bridge structure description informa- tion makes it a good candidate for XML; however this com- plexity also means that taking on the task of developing XML schema for all bridge types is beyond the scope of the current project. There will be a need to clearly define a manageable subset of structure types to focus on. In order to make this effort most productive, it is desirable to build upon existing work that has been accomplished within the AASHTOWare program on Virtis/Opis, and on prior NCHRP studies that have addressed bridge specification. The AASHTOWare Virtis/Opis Project provides a com- prehensive bridge domain which contains bridge descrip- tions for the purpose of structural analysis for many bridge types. These types include steel plate girder, rolled beam and built-up multigirder superstructures, reinforced concrete tee-beam and slab superstructures, sawn timber multibeam superstructures and precast, prestressed concrete I-beam and box-beam superstructures. Currently the Virtis/Opis soft- ware provides a reporting tool that produces an XML repre- sentation of the bridge domain. This XML information is used with a dynamic XSL template generator to produce user-defined reports for viewing using an Internet browser. The NCHRP Project 12-50 process provides a start for the definition of Bridge Specifications information. This process is currently being applied in research on several NCHRP bridge-related projects. Truck Permitting and Routing Each state has procedures for issuing permits to vehicles which exceed established size or weight limits for travel on state highways. A number of different permitting and routing applications are in place to select a permissible route for a vehicle based on the vehicleâs characteristics (length, axle configuration and weight) and the characteristics of the road networkâincluding bridge horizontal and vertical clearances and load ratings. A standard packet of information about bridge characteristics required for permitting and routing is a logical candidate for an XML schema. NBI Reporting/Data Exchange The Recording and Coding Guide for the Structure Inven- tory and Appraisal of the Nationâs Bridges defines a standard data structure for required annual NBI reporting on all pub- lic highway bridges. The current reporting format is a fixed format text file. NBI data is produced by bridge management systems (including AASHTOâs Pontis system) and many state DOTs have developed NBI reporting utilities that work with their bridge databases. NBI data is shared across different agencies and is used for a variety of analyses. Developing an XML schema for NBI data would provide a self-documenting format for NBI data and would provide a much-needed opportunity to address longstanding problems 29
with the fixed format (e.g., constraints on the number of dig- its for certain data items). It would allow for development of standard web services for validation, queries, and reports. Several changes to the NBI data items have been proposed, and an update is likely over the next couple of years. It would be best to roll out a new NBI XML format in conjunction with this update. Therefore, the timing was not right for develop- ment of an NBI XML schema as part of NCHRP Project 20-64. 4.5 Transportation Safety The transportation safety area involves many different business processes on the part of multiple agencies. Major processes include the following: ⢠Collection and processing of crash reports, including work flow to validate and approve reports across multiple agen- cies (state and local law enforcement, state highway safety office, state DOT); ⢠Federal reporting of safety data from state agencies and operators to NHTSA (Fatal Accident Reporting System, State Data System), FMCSA (SAFETYNET) and FRA; ⢠Linking crash data with other data sources (highway inventory, vehicle registration, driver licensing, enforce- ment, medical/injury control, road weather information) to provide information needed to analyze causal factors and outcomes; ⢠Sharing of crash reports within and across multiple agen- cies and organizations; ⢠Querying, reporting and mapping crash data based on a variety of criteria; ⢠Determining high-accident locations by conducting statis- tical analysis of crash data and vehicle miles of travel on different types of roadway sections; ⢠Analyzing crash information to develop strategic safety plans; ⢠Identifying and evaluating safety countermeasures for specific locations; ⢠Evaluating the safety implications of alternative facility designs and of alternative construction and maintenance practices, (including work zones); ⢠Commercial vehicle licensing, inspection, and permitting processes, including those related to hazardous materials transport; ⢠Real-time (ITS) management of incidents and emer- gency response activities; and ⢠Real-time (ITS) work zone safety management processes. Real-time exchange of incident information is already being addressed in the ITS arena; and exchange of motor car- rier safety information is being addressed within FMCSA. The two highest priority remaining opportunities for XML schema in the safety arena are for crash reporting and high- way safety analysis. These are discussed below. Crash Reporting Crash records are an obvious candidate for an XML schema. Crash records are used by many organizations and individu- als for a variety of different purposes. They are sufficiently complex to make manual reentry of data costly. Their accu- racy is critical. Even though crash data are not currently standardized, the Model Minimum Uniform Crash Criteria (MMUCC), the FARS reporting requirements, and ANSI D20 and D16 provide a solid base of widely adopted stan- dards on which to build an XML schema. Many states have uniform crash reports and are in various stages of imple- menting electronic crash reporting systems; several are already using XML. The AASHTO TSIMS design (5) recommends XML as the primary data exchange format for import and export functions, passing data to and from external legacy systems and the TSIMS data warehouse, and between TSIMS and external safety analysis applications. (Please note: As of the time NCHRP Project 20-64 was completed, the TSIMS project had been discontinued. It is anticipated that this proj- ect will be replaced by a new, reduced scope project entitled âSafety Management System.â) A standard crash record document (even a base that could be adapted by individual states) would facilitate implementa- tion of electronic crash reporting systems, reducing the time and cost of crash records processing. It would allow for devel- opment and sharing of software (e.g., web services) for ⢠Validating individual crash reports, ⢠Aggregating crash reports from different sources, ⢠Querying and reporting of crash data, ⢠Mapping of crash data, and ⢠Analyzing crash data. During the course of this project, NHTSA released an XML schema for crash records based on the MMUCC. This schema was developed in coordination with the Global JusticeXML effort, which had previously included some material for the driver history and citation elements of a comprehensive crash records schema, but not most of the MMUCC elements. Highway Safety Analysis While the MMUCC elements include some information on the characteristics of the crash site, it is impractical to col- lect detailed highway inventory information as part of a crash report. In order to identify high-accident locations, evaluate potential countermeasures and conduct safety analyses cor- relating highway characteristics to crash risks, it is necessary 30
to link crash data to highway inventory data via a common location reference. Therefore, in addition to an XML schema for crash data, it would also be beneficial to define a schema for a standard set of highway inventory elements that could be extracted from existing inventory systems for use in safety analysis. FHWAâs Safety Analyst software database is a good first cut at defining the inventory elements required for such analysis. The draft TSIMS data dictionary (which focused on highway data elements) and relevant location and linear ref- erencing elements needed to link crash records to highway inventory provide additional sources for such a schema. Functions/processes that could make use of this schema include the following: ⢠Get highway information for a crash and store it in an archive for statistical analysis and queries; ⢠Get highway information for a crash and use it to validate information on the crash report (e.g., consistency of dif- ferent location attributes of the crash record, pavement surface type, median type); ⢠Get safety-related highway inventory information for an identified high-accident location in order to identify and evaluate countermeasures; and ⢠Given a set of crashes over a given time period, establish peer groups based on highway characteristics, calculate average crash rates and/or hazard indices and identify high-accident locations. 31
