Click for next page ( 38


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



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 37
38 schemas that are defined in the instance document. The The semantic model developed for this project deviates instance document being validated can be made available on from the existing LandXML model where schema change rec- a web server, or alternatively, its body can be pasted in to the ommendations are proposed for consideration by LandXML validator form. in order to reduce ambiguity. In addition to these detailed The OGC validators can be accessed at: http://cite. recommendations, the following general recommendations opengeospatial.org/gmlTools/index.jsp. were made: Future Extensions--Rather than adding new elements to 5.6 TransXML Schema and future versions of LandXML, extend existing elements Sample Applications where possible. Where there are multiple ways of repre- The schema and sample applications developed for Trans- senting the same data (using different elements), the XML are briefly described below. See Appendix E for docu- chances are increased that a LandXML data set produced mentation of the schema, and Appendix F for electronic by civil design software application will not be suitable for versions of schema and applications. consumption by another application that reads LandXML As part of the UML modeling process, some common files. For example, one application that imports/exports building blocks were identified and packaged into three sep- alignments as CoordGeom elements and another applica- arate components for inclusion in multiple schema. These tion that imports/exports alignments as series of AlignPI components are as follows: elements will not be able to exchange alignment data even though they are both LandXML-compliant. If the intent A linear referencing schema based on ISO 19133, of adding the PI-based alignment element is to facilitate A reference schema that can be used to store master lists of reporting, a viable alternative would be to introduce a project pay items or funding sources, and provision whereby the LandXML 1.0 CoordGeom com- A TransXML base schema with various shared elements ponents of an alignment may be optionally grouped. This (e.g., addresses, phone numbers, project identifiers). grouping element may then carry optional attributes such as PI coordinates and stations. The current LandXML 1.1 AlignPIs element handles some common combinations Geometric Roadway Design Schema of spiral transitions, but was not designed to model three centered curves and tapered curves. The same goes for Description cross sections. Currently CrossSectSurfs models both The Geometric Roadway Design (GRD) schema defines design and existing cross sections. With the introduction the design control elements of a roadway, including hori- of DesignCrossSectSurfs, cross section data may be rep- zontal alignments, profiles, cross sections, superelevation, resented using two different methods, when there is no and geometric control features. This information is critical practical reason to do so. The state attribute may be used throughout the design process and must be communicated to delineate between existing versus proposed cross sec- clearly between various design stakeholders and design data tions, and it is not uncommon to encounter man-made consumers. The information is passed to construction so the existing sections such as existing pavement, existing side- road can be built. walks etc . . . that require the same flexibility as design The part of LandXML that addresses geometric roadway sections. design is the adopted TransXML schema in this area. This Coordinate Encoding--Implement stronger typing to facil- part of LandXML was adopted because it provides good cov- itate validation, change ordering of coordinates to be con- erage of the important information elements and already has sistent with the standard XYZ representation, make explicit an established base of user and vendor support. Work was whether the coordinates are 2D or 3D. conducted within the TransXML project with the aim of Units--Standardize and consolidate types of units used making a contribution to future development of LandXML. and improve documentation of which units are expected This work focused on the development of a UML model for the different elements. Rely on style sheets to render based on LandXML Versions 1.0 and 1.1. The purpose of this data in user preferred units. model was to provide a well-documented and unambiguous State Attributes--Review and revise use of state attributes view of the data contained in the XML schema (in order to to eliminate the potential for conflicting values between reduce the occurrence of inconsistent interpretations for container elements and their members. element and attribute meanings) and to identify and rec- Stations--Improve documentation for use of station attri- ommend improvements to extend the usefulness of the butes to distinguish between internal stations (beginning LandXML schema. station plus cumulative length) and user station values.

OCR for page 37
39 Consider adding qualifiers to distinguish the type of station the awarded contractor's price, and any price adjustments value provided. made by change orders after the project is let. Naming Conventions--Improve consistency in naming Finally, the schema also allows for inclusion of location ref- conventions for data types and code list elements. erencing for the design project. A shared TransXML linear referencing schema is used for this purpose. A sample application of the Design Project schema was Resource Documents developed that demonstrates: Crews, N., E. Hall, and D. Rebolj, LandXML Schema Ver- sion 1.0 Reference, 2002; Retrieval of a list of master pay items (display and query Crews, N., LandXML-1.0.xsd; and from an instance document for the reference schema with Crews, N., LandXML-1.1.xsd. pay items); Creation of a subset of pay items from this master list for use in a design project (creation of a new reference instance Design Project Schema document with pay items); and Creation of a design project from the project-specific pay Description item list, including quantities and unit prices (creation of The aecXML Infrastructure schema provided the means a design project instance document). for roadway designers to obtain information about possible pay items available for use on a design project, and allowed The application was developed based on the JavaServer them to specify which of these will actually be used on the Faces technology, using the Sun Java Studio Creator 2 as an project. The TransXML Design Project schema builds on this IDE. This application runs on any servlet container that imple- and adds pay item quantity and cost information. This extends ments the JavaServer Pages specification 2.0, such as "The the value of the schema, allowing for transfer of data to the Apache Tomcat 5.5 Servlet/JSP Container." following: The Estimator--Who will use it to determine the estimated Resource Documents cost of the project, IAI aecXML Domain Committee, aecXML.xsd. The Plans Developers--For preparation of the contract documents, and The Contract Administrator--For preparation of the bid Area Features Schema proposal. Description The Design Project schema was developed in coordination The Area Features schema represents information about with the Bid Package schema so that information created in area features such as environmental areas, soils, wetlands, the design phase can be augmented (not recreated) for use in land use, flood plains, site improvement areas, right-of-way, the construction phase--both for electronic bidding, and for and cadastral information. Of primary concern to the designer construction inspection and tracking. A separate reference is the location of these areas with respect to the roadway proj- schema was created for master lists of pay items and funding ect being designed. This information is typically stored in a sources to provide a common link across the Design Project GIS but would be helpful if it could be included as a backdrop and Bid Package schemas. to a CAD design drawing. The Design Project schema includes information about pay Currently LandXML includes land parcels as the only area items (ID, type, description, units of measure) as well as a list features and it approaches these from the perspective of sur- of contract pay items and their respective funding sources on veying. The Area Features schema was developed to provide a given project. It also supports the concept of multiple design a more general purpose area feature capability. It supports the alternates for different aspects of a given project. transfer of features information from agencies outside of the The schema is designed to support evolution of cost infor- design office, such as planning, National Wetlands inventory, mation from the initial estimate through multiple iterations counties and municipalities, FEMA, right-of-way, soils, and of the design, and on to bidding and letting. Various costs are consultants. included, including the designer's initial estimated cost on Area features are common to most GIS software and pay items for an individual project, an estimators estimated have been standardized by ISO TC211. The TransXML Area cost per item on the project and for a proposal which may Features schema is consistent with TC211, and makes use include several projects, each contractor's pay item bid price, of the native GML elements for spatial representation of

OCR for page 37
40 surfaces. The schema supports XML documents containing Time bidding and other situations where contractors bid on a single area feature as well as documents containing col- time to complete milestones. lections of features (e.g., all of the lakes and ponds within a Thousands of transportation proposal bid packages are county). published each year, often in paper form, to a community of A sample application (Import TransXML Area Features) tens of thousands of contractors, subcontractors, and suppli- was developed to demonstrate use of the Area Features schema. ers. The standard transportation Bid Package XML schema This application allows the user to import and display GIS area will enable agencies to publish bid packages electronically in features from an XML instance document into a Microstation a standard form that can be directly loaded into bid prepara- CAD design drawing. Sample data files are provided repre- tion systems. As a result, information flows will be stream- senting seeding, erosion, and pond areas. The application was lined, and redundant data entry and the associated opportunity developed on Microstation Version 08.05.01.xx Windows x86 for error will be substantially reduced. using MDL (Microstation Development Language). The TransXML Bid Package schema package incorporates the TransXML Design Project, Reference, and Linear Refer- encing schemas. Resource Documents A sample application was developed using XSLT to create Crews, N., E. Hall, and D. Rebolj, LandXML Schema Ver- an HTML Bid Package report from an XML instance docu- sion 1.0 Reference, 2002; ment based on the TransXML Bid Package XML Schema. Crews, N., LandXML-1.0.xsd; Burggraf, D., LandGML0.6.xsd; Resource Documents ISO, ISO/TC 211/WG 4/PT 19136 Geographic Information--Geography Markup Language (GML), ISO IAI aecXML Domain Committee, aecXML.xsd and CD 19136, February 7, 2004; aecXML_infra_v33.xsd; and Ron Lake, David S. Burggraf, Milan Trninic, and Laurie AASHTO, AASHTOWare Trnsport product documen- Rae, Geography Mark-Up Language, John Wiley & Sons, tation. Inc., San Francisco, California, 2004; and ISO 19107, Geographic Information--Spatial Schema, International Organization for Standardization, Geneva, Construction Progress Schema 2001. Description At the project construction site, inspectors record daily Bid Package Schema construction progress on pay items. This information is gath- ered by project inspectors and communicated to the project Description engineer. The project engineer prepares a progress estimate In preparation for letting a construction contract, trans- using this information and submits it to the central office to portation agencies publish a proposal bid package. Contractors trigger a progress payment to the contractor. use this information to prepare their bids. Subcontractors and The information being exchanged includes pay item descrip- suppliers use this information to identify potential business tive information, and partial quantities placed and placement opportunities and submit quotes to primary contractors. In locations. The Construction Progress schema builds upon the the event that project changes occur after publication but Design Project schema to enable association of a location with prior to the letting, the agency publishes these changes in pro- a partial quantity placed. posal amendments. A broad range of field devices are used to measure con- The bid package includes general proposal and pay item struction progress. Various elements of this information are information. Proposal amendments can include changes to communicated frequently among field, project office, test lab, any element of this information. The Bid Package schema and central office personnel throughout the construction proj- builds upon the Design Project schema to support the letting ect. A standard XML schema for this information will enable process requirements for publishing bid packages. The Infra- integration of the diverse data collection and data management structure Project schema is augmented with additional pro- systems utilized to track this information, thereby streamlin- posal information including the letting location and date, ing information flows and reducing the opportunity for error. vendor qualification requirements, contract time informa- The TransXML Construction Progress schema package tion, and the additional attributes required for amendments. incorporates the Materials Sampling and Testing schema, the Proposal milestones are also included to support Cost Plus Bid Package schema, and the Reference schema.

OCR for page 37
41 An application was created to generate an HTML webpage An application was developed using XSLT to produce a web- showing a Daily Construction Diary for a project as described page showing the sampling and testing activity for a material in a TransXML Construction Progress Report XML instance sample as described in a TransXML Material Sampling and document. This web page can be used to review daily con- Testing XML instance document. This webpage can be used struction progress. The daily construction diary web page is to review the sampling and testing status and results for a generated by applying an XSLT stylesheet to a TransXML material sample. Construction Progress Reporting XML instance document. The colors and styles of the web page are defined using cas- Resource Documents cading style sheets. IAI aecXML Domain Committee, aecXML.xsd and aecXML_infra_v33.xsd; and Resource Documents AASHTO, AASHTOWare Trnsport product documen- IAI aecXML Domain Committee, aecXML.xsd and tation. aecXML_infra_v33.xsd; and AASHTO, AASHTOWare Trnsport product documen- Project Construction Status Schema tation. Description Materials Sampling and Testing Schema Project stakeholders including the general public, elected officials, oversight or regulatory agencies, and other institu- Description tions such as utilities and railroads require or can benefit from access to timely information about the status of a trans- At the project construction site, inspectors record daily portation construction project. This information is managed construction progress on pay items. Associated with pay item within the agency in their construction management system. progress is a parallel tracking of the component materials of The information is provided to different stakeholders in dif- the pay item and the extent to which these materials meet the ferent forms. agencies materials testing requirements. This information is The information being exchanged includes project descrip- gathered by project inspectors and laboratory personnel and tion, location, and fiscal, schedule and progress informa- communicated to the project engineer. The project engineer tion including milestone dates and those affecting traffic. prepares a progress estimate using this information and sub- The Project Construction Status schema builds upon the mits it to the central office to trigger a progress payment to Design Project schema to support publication of project the contractor. construction status information. This schema was augmented The information being exchanged includes materials sam- with additional milestone dates, and fiscal and progress pling and testing requirements, materials samples collected, information. field tests performed, test acceptance methods, and the out- This XML schema will enable the automated publication come of those tests. The Installed Quantities and Materials of transportation project status information in a standard Used and Tested schema builds upon the Design Project format that can be presented in a variety of forms appropri- schema and encompasses material samples collected, field ate for the individual target audiences. tests performed, and the outcome of those tests. A sample application was developed using an XSLT A broad range of field devices are used to track material stylesheet to generate an HTML project construction status use, sampling, and testing. Various elements of this informa- web page for the projects in a contract as described in a Tran- tion are communicated frequently among field, project office, sXML Project Construction Status XML instance document. test lab, and central office personnel throughout the con- This web page can be published on a public website to pro- struction project. A standard XML schema for this informa- vide project status information to interested stakeholders. tion will enable integration of the diverse data collection and data management systems utilized to track this information, Resource Documents thereby streamlining information flows and reducing the opportunity for error. IAI aecXML Domain Committee, aecXML.xsd and The TransXML Materials Sampling and Testing schema aecXML_infra_v33.xsd; and package incorporates the TransXML Design Project, Con- AASHTO, AASHTOWare Trnsport product documen- struction Progress, and Reference schemas. tation.

OCR for page 37
42 Bridge Design and Analysis Schema constraints, the adoption of GML was less rigorous for this schema. A bridge was at least defined as a subtype of GML Description feature to enable GML-aware software to recognize it and The purpose of the TransXML bridge design and analysis handle it accordingly, for example, display it on a map along schema is to allow for transfer of bridge description informa- with other features. tion across bridge structural analysis packages to allow for A sample application, the TransXML Bridge Input Con- comparative analysis of the same bridge using multiple bridge verter, was developed to demonstrate the translation of a analysis processes. Bridge TransXML instance document produced by one piece The AASHTOWare Virtis/Opis bridge domain was used of bridge analysis software to a format that could be inter- as a starting point for the development of the TransXML preted by another bridge analysis software package. An exam- Bridge Analysis/Design schema. The AASHTO Virtis/Opis ple is provided with the application that uses a TransXML bridge domain provides a comprehensive description for instance document of a prestressed concrete bridge generated the purpose of analyzing many bridge types. These types from the AASHTO Virtis database to create an input file that include steel plate girder, rolled beam and built-up multi- can be processed by the Pennsylvania Department of Trans- girder superstructures, reinforced concrete tee-beam and portation's LRFD Prestressed Concrete Girder Design and slab superstructures, sawn timber multibeam superstruc- Rating (PENNDOT PSLRFD) software. While this applica- tures and precast, prestressed concrete I-beam and box-beam tion demonstrates the conversion for this specific software superstructures. Due to the complexity of this domain and package, the concept for the conversion is applicable for other limited resources, the following subsets of the Virtis/Opis software packages that utilize an input file/output file method structure types were included in this initial bridge structure of operation. schema for TransXML: Resource Documents Multigirder steel rolled beam and steel plate girder girder- line structures, AASHTO Virtis/Opis Database and API documentation; Multigirder prestressed concrete I-beam and box-beam M. Mlynarski, J. A. Puckett, C. M. Clancy, M. C. Jablin, and girder-line structures, P. D. Thompson, NCHRP Report 485: Bridge Software Val- Multigirder reinforced concrete tee-beam and I-beam idation Guidelines and Examples, Transportation Research girder-line structures, and Board, Washington, D.C., 2003; and Reinforced concrete slab-line structures. PENNDOT LRFD Software manuals. This subset covers roughly 75 percent of bridge structure types--it excludes only timber multigirder, floor systems Crash Report Schema (girder-floorbeam-stringer), and girder-system definitions. Description The Virtis/Opis software provides a reporting tool that produces an XML representation of the bridge domain. Information about highway crashes is recorded in police Before being implemented into the Virtis/Opis software, reports, and then transferred to a variety of other agencies the XML structure was reviewed and approved by AASHTO (Registry of Motor Vehicles, DOT, courts, etc.) for process- Technical Advisory Group members from nine different ing, archiving, and analysis. In many states, crash reports and states. This XML information is used with a dynamic XSL crash reporting practices are not uniform across jurisdictions. template generator to produce user-defined reports for view- However, there is some degree of commonality to crash ing using an Internet browser. While the output is in XML data--crashes involving fatalities are subject to the NHTSA format, there is no corresponding XML schema. Based on Fatal Accident Reporting System (FARS) requirements; and input from the AASHTO BridgeWare community, a decision a minimum set of data elements (the Model Minimum Uni- was made to constrain the structure of bridge data in devel- form Crash Criteria or MMUCC) have been developed by oping the TransXML bridge schema so that little or no mod- NHTSA, FHWA, and the National Association of Governors' ifications would be required to make XML output from the Highway Safety Representatives in the interest of achieving current Virtis/Opis report writer validate against the Trans- greater uniformity in crash data. XML bridge schema. This was a case in which the desire to The purpose of the Crash Report schema is to provide a have TransXML accepted by a major stakeholder group standard data exchange format for the information recorded (AASHTO BridgeWare users) had to be traded off against the at the time of the crash (not the information which may be objective of a schema development process that responded to linked to the report after the crash). This format can facilitate a wider spectrum of organizations. Because of the preexisting transfer of crash data from collection systems to systems that

OCR for page 37
43 validate the data; from validation systems to archival data- Highway Information Safety bases; and from archives for reporting, aggregation, and Analysis Schema analysis applications. A UML model for crash records was developed based on Description the Model Minimum Uniform Crash Criteria (MMUCC), The Highway Information Safety Analysis schema describes and the FARS reporting requirements. On completion of safety-related highway inventory items that relate to a specific this UML model, NHTSA released an XML schema for the incident location. It provides a set of data elements that can be MMUCC elements that was developed in coordination with integrated with crash data in order to identify high-accident GJXDM. Prior to this schema's release, detailed information locations, analyze the need for engineering countermeasures, or about its content was not publicly available. In order to avoid evaluate specific countermeasures proposed for a location. The duplication of resources (and production of a competing schema was based primarily on the FHWA's SafetyAnalyst data crash records schema), the research team recommended that dictionary. Its design also considered the contents of the pre- the NHTSA MMUCC XML schema be adopted by Trans- liminary TSIMS data dictionary that defined a preliminary set XML. The TransXML UML model was provided to NHTSA of highway inventory items that are required for safety analysis. along with some comments regarding inclusion of FARS It was originally intended to build upon either ISO 14825 elements into the schema. The research team was informed Geographic Data Files (GDF) or the FGDC Framework Data that subsequent versions of the schema would include the Content Standard (formerly Geospatial One-Stop) as the FARS elements that could not be translated from existing infrastructure base. As part of the National Spatial Data Infra- MMUCC elements. structure (NSDI) initiative, the latter appeared to be more The research team developed a sample application to appropriate. However, it is only now becoming stable enough demonstrate how multiple sources of crash data using differ- for consideration. What has been provided for HISA appears ent XML schemas can be combined in a single crash report. to align well with the Framework standard. As TransXML This application merges two XML data files--one using the evolves beyond Project 20-64, it would be our recommenda- NHTSA MMUCC XML schema, and the other using a dif- tion to include Framework inside TransXML with appropri- ferent schema such as those that might be used by a state or ate connections to HISA. municipality. XSLT allows the application to link together A sample application was developed that allows users to any crash records schemas. The columns shown in the report search through crash records stored using the NHTSA can be changed by modifying the XSLT files. MMUCC XML schema, and to link these crash records to The MMUCC XML schema is available at: http://www. related highway safety information stored using the HISA crashdata-xml.us/. This site also includes a demonstration of schema. Users can search based on four sample data fields, an Electronic Data Transfer (EDT) gateway server to have and a small set of data fields are presented for each crash Police Accident Reports (PAR's) immediately forwarded to record. The program can easily be extended to search on or the FARS case management system as soon as they are display additional data fields. entered into the state crash records database. NHTSA is fund- Any XML file that conforms to the NHTSA MMUCC XML ing a pilot program for states wishing to implement this EDT schema can be filtered and viewed by this application. Crash capability. records stored using a different XML schema can be con- verted to the NHTSA schema using XSLT. XSLT also allows Resource Documents data from multiple XML data files to be combined. In this sample application, Highway Safety Information associated Model Minimum Uniform Crash Criteria Guideline, Second with each crash (stored in a separate XML file) is presented Edition (2003); alongside each crash record. While the linkage between these ANSI Standard D20-2003 Data Element Dictionary for two sample data sets is arbitrary, the application shows how Traffic Records Systems, American Association of Motor these two schemas can be used together to create a complete Vehicle Administrators, April 2003; view of a crash. An XSLT file is used to customize the for- ANSI Standard D16.1-1996 Manual on Classification of matting of each crash record. Any data item in the NHTSA Motor Vehicle Traffic Accidents, Sixth Edition; MMUCC XML schema that can be expressed with XPath can 2004 Fatal Accident Reporting System Coding and Valida- be removed or added as a category in the search filter. tion Manual, NHTSA; Transportation Safety Information Management System, Resource Documents Phase I Consolidated Report, prepared by Littleton PRC, June 2001; and Model Minimum Uniform Crash Criteria Guideline, Sec- JXDM-3.0.2.xls (from http://it.ojp.gov/jxdm/3.0.2/). ond Edition (2003);

OCR for page 37
44 ANSI Standard D20-2003 Data Element Dictionary for Transportation Safety Information Management System Traffic Records Systems, American Association of Motor Data Dictionary; Vehicle Administrators, April 2003; American National Standard for Information Technology-- 2004 Fatal Accident Reporting System Coding and Valida- Geographic Information Framework--Data Content Stan- tion Manual, NHTSA; dards For Transportation Networks: Roads, Information Transportation Safety Information Management System, Technology Industry Council; Phase I Consolidated Report, prepared by Littleton PRC, Highway Performance Monitoring System Manual; and June 2001; FHWA SafetyAnalyst data dictionary (draft).