National Academies Press: OpenBook

TransXML: XML Schemas for Exchange of Transportation Data (2007)

Chapter: Section 5 - TransXML Process and Products

« Previous: Section 4 - Gaps and Opportunities for TransXML
Page 31
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 31
Page 32
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 32
Page 33
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 33
Page 34
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 34
Page 35
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 35
Page 36
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 36
Page 37
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 37
Page 38
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 38
Page 39
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 39
Page 40
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 40
Page 41
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 41
Page 42
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 42
Page 43
Suggested Citation:"Section 5 - TransXML Process and Products." National Academies of Sciences, Engineering, and Medicine. 2007. TransXML: XML Schemas for Exchange of Transportation Data. Washington, DC: The National Academies Press. doi: 10.17226/14027.
×
Page 43

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.

32 This section describes both the process used to develop TransXML schema, and the work products of the effort. 5.1 Schema Development Process A schema development plan was prepared based on the analysis of gaps and opportunities presented in Section 4. This plan identified the schema and sample applications to be developed, defined the technical standards and processes to be followed in order to provide consistency across the schema, and established mechanisms for stakeholder involvement. Table 3 summarizes the work included in the schema development plan. An initial activity in the plan was to con- duct an experiment to determine whether the XML encoding for TransXML should be based on the Geography Markup Language (GML). This would allow the TransXML effort to take advantage of a rigorous XML foundation, a structured approach that enhances interoperability and tie-in to open geographic data standards. This experiment was conducted, and after considerable debate, the decision was made to adopt GML for new schema but to allow for inclusion of pre- existing, non-GML-compliant schema into TransXML. This approach struck a balance between establishing a consistent framework for TransXML on the one hand, and avoiding duplication of existing, accepted XML schema. Section 5.2 discusses the technical standards established for TransXML and the results of the GML experiment. A total of 10 data exchange topic areas were selected for detailed data modeling. For one of these areas—Geometric Roadway Design—the schema development plan called for data modeling only, with no XML schema development. This decision was made because of the large and well-established user base of LandXML. In lieu of developing a new TransXML schema, the project team recommended enhancements for consideration by LandXML.org. For a second area—Crash Records—data modeling was completed, but a decision was made not to implement a TransXML schema. Instead, the project team elected to adopt the NHTSA crash records schema that was released during Phase II of the TransXML project. Thus, eight new schema were developed for TransXML, and two external schema were adopted (NHTSA MMUCC XML and a subset of LandXML). The schema development process involved the following steps: • Solicit participation in schema development by key stake- holder groups for each of the schema areas through net- working, e-mails, and establishment of a collaboration website for TransXML. Stakeholder involvement is dis- cussed in Section 5.3. • Develop UML models for each of the schema areas in order to gain consensus on data content and structure, and revise based on stakeholder comments. The UML modeling effort is described in Section 5.4. • Develop XML schema and sample applications. The process used to generate the schema is described in Section 5.5; the content of the schema and applications is described in Section 5.6. 5.2 Technical Framework for TransXML Schema Development Standards Schema development standards were established to ensure consistency across the different schema efforts undertaken as part of TransXML. They also provided for adherence to W3C standards for XML schema and for the use of best practices which are generally accepted in the broader community of XML schema developers. In order to define development standards for TransXML, the following sources were consulted: • AASHTOWare Standards and Guidelines Notebook: http://aashtoware.org/docs/020820_Complete_Viewable_ S&G.pdf (or see AASHTOWare.org); S E C T I O N 5 TransXML Process and Products

• Draft Federal XML Developers Guide (2002) http://xml. gov/documents/in_progress/developersguide.pdf; • aecXML Style Guidelines: http://www.iai-na.org/aecxml/ documents.php; • LandXML Detailed Documentation: http://www.landxml. org/spec.htm; • JusticeXML naming conventions training slides: http:// justicexml.gtri.gatech.edu/workshop/Day2/9_Naming. pdf; and • GML: http://www.opengeospatial.org/docs/02-023r4.pdf— Section 8. The following guidelines were established: • The Schemas will conform to the W3C XML Schema Rec- ommendations: http://www.w3.org/XML/Schema; • Use of attributes within TransXML schema will be limited to conveying metadata about elements that are relevant only within the local scope of the element and are not likely to require further extension or parsing; • New TransXML schema will avoid duplication of existing elements of related schema that are currently in wide- spread use through use of inclusion methods; 33 Item Scope Comments A. GML Experiment Experiment done in order to make an informed decision about basing TransXML on GML. B. Geometric Roadway Design (GRD) Exchange of roadway geometric design information across design and survey software packages, and for machine control. No XML produced – enhancements suggested to LandXML.org based on UML modeling. C. Design Project (DP) Exchange of design project pay item data across design, cost estimation, and bid preparation software. Renamed from “Contract Pay Items” in original Schema Development Plan. D. Area Features (AF) Exchange of area features data (e.g., wetlands locations) across GIS and CAD systems. E. Bid Package (BP) Exchange of construction bid package data between agency systems and contractor bid preparation software. F. Construction Progress (CP) Exchange of information about the progress of a construction project in terms of partial pay item quantities placed. This was originally combined with materials testing in the original Schema Development Plan. G. Materials Sampling and Testing (MST) Exchange of construction site installed quantities and materials used and tested information from field data collection systems to laboratory systems and central construction progress tracking and contractor payment systems. Renamed from “Construction Quantities and Materials” in original Schema Development Plan. H. Project Construction Status (PCS) Publication of construction project status information to stakeholder information systems (e.g., project web sites, partner agencies). I. Bridge Design and Analysis (BDA) Conduct bridge structural analysis in multiple software packages without the need to reenter data; compare analysis results across systems. J. Crash Report Exchange of crash data from police reports to validation/processing systems and archives; enables standard queries of crash databases. (NHTSA/Justice MMUCC XML Schema adopted as part of TransXML). K. Highway Information Safety Analysis (HISA) Exchange of highway inventory information between inventory systems and safety analysis software. Table 3. TransXML schema development.

• The most appropriate and restrictive data types will be used for element types and attributes; • A default namespace will be used to avoid the need to qual- ify all element types and attributes with namespaces; • The temporary namespace placeholder: “http:/www. transxml.net/schema” will be used as the default namespace in the development of TransXML schema; • All element names will be self-explanatory and meaningful to subject matter experts; • Plural case shall only be used for element names that rep- resent lists. Otherwise, singular case shall be used; • Upper Camel Case will be used for schema elements and data types (e.g., “UpperCamelCaseElement”); • Lower Camel Case will be used for properties (e.g., “lower- CamelCaseProperty”); • Schema component names will not contain Underscores (_), Periods (.), and Dashes (—); • Schema element and attribute names will not use abbrevi- ations, unless there is agreement among stakeholders that the abbreviations are widely understood and that they are necessary for conveying the element meaning; and • Schema element and attribute names should avoid the use of acronyms, unless the resulting names would be unrea- sonably verbose and/or the acronyms are nationally recog- nized. If acronyms are used, they will be spelled out within schema annotations. Even with adoption of the schema development standards described above, the W3C XML Schema specification leaves considerable room for structural and stylistic differences across schema developers. Also, it was apparent the schema in the transportation field needed to make use of data elements that are required in other application areas—most notably for loca- tion, but for other elements as well. The research team felt strongly that associating TransXML with an existing XML effort that provided a consistent technical framework, including foundational elements, would provide a leg-up for TransXML. The GML was identified as the most promising base for TransXML. The other option would have been the Global JusticeXML Data Model (GJXDM), which has been emerging as a foundation for XML efforts in the Justice, and more recently, Homeland Security communities. While either choice would have been beneficial for TransXML, GML was consid- ered to be better aligned with the types of schema to be pro- duced under TransXML. In particular, it provided better treatment of information describing physical objects and their properties (including geographic location), as well as consis- tency with adopted open geospatial standards. Geography Markup Language The GML is a set of XML building blocks designed to be a foundation on which specific industries, like transportation, can develop domain-specific application schemas. A GML schema follows the W3C XML schema standard so all GML- compliant schema are also XML-compliant and can be vali- dated with available XML tools. GML was developed by the Open Geospatial Consortium (OGC) and is a draft ISO stan- dard within the TC 211 191xx family of GIS-related stan- dards. GML is the format for request and response messages for OGC Web Feature Services (WFS), which means that a variety of web applications for querying and serving geo- graphic data from a variety of sources are being designed to understand GML. Even though GML is clearly a product of the geospatial data community, it is not only a markup language for geo- graphic data. It provides an equally valid approach to XML encoding for applications that have no geographic content. It claims to be an “XML-based mark-up language used to encode information about real-world objects [features].” These features can be concrete (tangible) like roads and bridges or abstract like property or jurisdictional boundaries. GML pro- vides a standard way to represent features, and properties of these features, which can include (but does not need to include) information about their location and geometry. For example, GML can be used to provide multiple representa- tions of a roadway—its abstract characteristics (e.g., func- tional classification), its location in space and along a longer route, and its horizontal and vertical alignments. The feature- centric approach supports data exchange across the enter- prise because it allows for objects (such as roads) to have geometrical representations of different types and at differ- ent levels of precision, supporting a variety of applications (including inventory, GIS, and CAD). The guidance and structure provided by GML results in more uniform schemas which are more human readable and predictable for software processing. The tradeoff to be made in adopting a foundation such as GML (or GJXDM for that matter) as the basis for TransXML is the additional complex- ity for schema developers and overhead imposed on the XML files themselves. In order to explore this issue, an experiment was conducted which involved developing parallel XML and GML schema, instance documents, and extraction programs for a candidate application area. The results of this experi- ment are provided in Appendix B. Key conclusions of this experiment were as follows: • Use of GML required less effort in developing schemas than straight XML because standard, predefined GML types provided a foundation upon which to build TransXML- specific types. These include features, xlinks, basic types (for measurements, codes, etc.), geometry, topology, ref- erence systems, temporal, units of measure, and styles. • The GML application schema was easier to read than the straight XML schema. This is because the GML schema was less cluttered with basic type definitions. The GML object- 34

property approach encouraged stronger typing, which reduces the ambiguity evident in less structured approaches. • There was no significant difference in the instance docu- ments (.XML files) from the XML and GML schemas. GML has a few extra lines for tags due to the object-property dis- tinction. The difference in case (UpperCamelCase con- vention for objects, lowerCamelCase for properties) for element tags clarifies the difference. The XSL documents which generate sample reports from XML and GML instance documents are virtually identical due to the similarity in instance documents. In order to reduce overhead in processing of GML-based TransXML schema, a decision was made to use a subset of GML for TransXML. This subset of GML 3.1.1 is based on the current OGC proposal for Simple Feature GML (SFGML), in OGC 05-033r24, GML simple features profile, Appendix D, March 7, 2006. 5.3 Stakeholder Involvement Stakeholder Identification and Communication Stakeholders for each of the business areas were identified, and an e-mail list was developed to inform these individuals and groups about the TransXML project and encourage their participation. Information about the project was also sent to the AASHTO and TRB liaisons at all state DOTs, and to rele- vant TRB committee chairs for further distribution. The May 2005 TRB e-newsletter included a blurb on the project with a link to the TransXML website. Presentations on TransXML were given at the September 2004 International Highway Engi- neering Exchange Program conference in Lincoln, Nebraska; the January 2005 TRB annual meeting in Washington, D.C.; the May 2005 AASHTO Information Systems Subcommittee meeting in Baton Rouge, Louisiana; and the August 2005 Traffic Records Forum in Buffalo, New York. Two press releases for the project were issued—one in the spring of 2005 and a second in January 2006. Articles on the project were pub- lished in the AASHTO Journal in May 2005; and in the Spring 2005 edition of the AASHTO Trns•port News. Key stakeholder groups identified for the different business areas were as follows. Roadway Survey/Design • DOT design divisions, • Civil design software vendors, • Engineering firms, • LandXML.org, • aecXML Infrastructure Working Group participants, and • Current IAI aecXML Domain Committee members. Construction/Materials • AASHTO, • FHWA, • Construction management software vendors, • Construction contractors, • aecXML Infrastructure Working Group participants, and • Current IAI aecXML Domain Committee members. Bridge Structures • AASHTO Virtis/Opis Panel, • Bridge software developers, • Bridge design firms, and • DOT bridge engineers. Highway Safety • NHTSA, • FHWA Safety Office/Turner Fairbank Highway Research Center, • The Association of Traffic Safety Information Professionals (ATSIP), • National Safety Council, • Iowa DOT TraCS Consortium, • AASHTO TSIMS representative(s), • GLOBAL JusticeXML, and • COMCARE Alliance. Collaborative Website An interactive website was developed to enable a collabo- rative process of schema development. The “transxml.net,” “transxml.org,” and “transxml.com” domain names were reserved and were directed at this site. The website included the following features: • Background information on the TransXML project, includ- ing an overview presentation on the project that can be downloaded, a list of contacts, and schedule information; • Links to external sources of information about related XML and data standards efforts; • A section for each business area, with capabilities for stake- holders to review sources and resource materials, down- load draft documents, submit comments and proposed revisions, and participate in threaded discussions on rele- vant topics; • Automated notification for interested registered users when new material is added to specific areas of the site; and • A protected area for the development team to share docu- ments and links to external resources. A moderator was assigned for each of the four business areas. Moderators were responsible for posting relevant 35

materials to the website, and monitoring and responding to stakeholder comments. An administrator for the entire website managed general project content (not specific to a business area) and user priv- ileges. The website was set up with public areas containing general project information and a working group section for each of the four business areas. Stakeholders interested in joining working groups were able to register on the site. The site administrator then granted them access to the relevant working groups, allowing them to read and download mate- rials, and participate in discussions. Registration was required to prevent spamming, but it may have presented an obstacle to achieving greater stakeholder participation—particularly since there was a time delay between registration and grant- ing of access. The initial website went live on March 26, 2004. As of the end of June 2004, over 100 individuals had signed up on the website to be on the project’s mailing list and/or participate as schema developers or reviewers. At the close of the project, 376 peo- ple had registered on the website. While several general comments were made at the start of the project, and a few individuals did perform a detailed tech- nical review of UML models and submitted comments, the overall level of participation in the TransXML project was considerably lower than anticipated. The collaborative website was developed using open source. NET software. The entire site, including the supporting data- base with all site content is being provided to NCHRP as part of the deliverables for this project. 5.4 UML Modeling Unified Modeling Language (UML) class diagrams (ISO Standard 19501) were used as the primary design tool for the XML schemas developed for TransXML. UML modeling is standard practice—several standards bodies (OpenGIS, TC211, TC204), have adopted UML as their modeling language of choice. While XML Schemas are humanly readable, it is extremely difficult to grasp the data relationships being rep- resented in an XML schema (.xsd) document. UML models present this information graphically and symbolically, facili- tating the review process. Just as it is always easier to modify software (or any constructed item) in the design stage than after it is under construction, it is much easier to modify UML models than completed XML schema. In addition to facilitat- ing the design review process, UML diagrams also serve as use- ful documentation for the XML schema and are invaluable for supporting maintenance of the schema over time. Figure 5 shows a sample UML class diagram. This diagram conveys the following information: • A road project is composed of 0 or more road project pay items. • A road project has three attributes: a project number, a project name, and a project engineer. The project number has a special ID data type; the project name and project engineer attributes are character strings. • A road project pay item has two attributes: quantity and esti- mate. Both quantity and estimate are numerical data types. • A road project pay item must correspond to an entry on a standard contract pay item list. • A standard contract pay item is described by four attributes: an item number (ID), an item name (character or string), an optional description (character string), and units of measure (which is a special measurement units data type). • Measurement units must be selected from a code list, which has four fixed choices: linear feet, cubic yards, tons, or each as well as an option for a user-specified other value. 36 + linearFeet + cubicYards + tons + each <<CodeList>> TG_MeasureUnits + projectNumber: ID + projectName: CharacterString + projectEngineer: CharacterString <<Type>> RD_Project + quantity: Number + estimate: Number <<Type>> RD_ProjectPayItem 0..* 0..* + itemNumber: ID + itemName: CharacterString + description[0..1]: CharacterString + units: TG_MeasureUnits <<Type>> RD_ContractPayItem 1 +project item +standard item Figure 5. Sample UML class diagram.

Two UML modeling tools were utilized within the develop- ment team: (1) IBM’s Rational Rose (an “industrial strength” tool) and (2) Sparx Systems Enterprise Architect (a lower-cost UML modeling tool). Appropriately, an XML-based modeling data exchange format (XMI) was used to transfer model information across the two tools. Standard conventions for the TransXML UML models were established and documented for use by the data model- ers from the four business areas. A presentation was devel- oped on how to read UML class diagrams, and posted to the TransXML website as a resource for stakeholders wishing to comment on the diagrams. UML models for the selected TransXML schemas are doc- umented in Appendix C. 5.5 GML Encoding and Validation Creation of GML Application Schemas for TransXML The TransXML schemas make use of the Open Geospa- tial Consortium GML simple features profile, which is a subset of GML. This subset was developed to simplify the process of writing software that generates and parses the GML/XML documents. The simple features profile is described in OGC document [OGC 05-033r24] (Copyright ©2005 Open Geospatial Consortium, Inc. Used with permission. All Rights Reserved. To obtain additional rights of use, visit http://www.opengeospatial.org/legal/ which explains what needs to be in the schema.) The Open Geospatial Consortium has made available a program called ShapeChange which converts UML into GML. Documentation on the ShapeChange tools can be found at: http://www.interactive-instruments.de/ugas/. The ShapeChange tool was used to create an initial or partial cut at each of the TransXML schema except for the bridge design and analysis schema. This last schema was created through a separate process to ensure consistency with the existing Virtis/ Opis XML report generator output (see Section 5.6 for fur- ther information). Experience with the ShapeChange tool was mixed. The tool makes certain assumptions about element namespace prefixes which did not always agree with the conventions established for TransXML. For example, we use “xs” for all W3C elements and nothing for the namespace of the schema being defined. ShapeChange does the opposite. TransXML also has adopted a uniform order to elements in a schema file: root element, alphabetized base property types, other prop- erty types (also alphabetized), and finally alphabetized enu- merations and code lists. It was not apparent what order ShapeChange used. ShapeChange was useful in generating the enumerated and code list types, to reduce manual entry. It also provided verification of the structure and content of GML constructs. In order to guide development of future TransXML schema, a template UML model and a companion template.xsd file were developed. Future TransXML Schema Validation For the purposes of future development of XML schemas under the TransXML umbrella, the following requirements are recommended: 1. The schema should conform to the rules for the GML simple feature subset; and 2. The schema should utilize the linear referencing standards outlined in ISO 19133 (Clause 6.6) for all linear referencing. OGC is currently preparing an abstract test suite that will enable TransXML schema developers to ensure that the first of these two requirements is met. Because of their focus on GML, their test suites are likely to be more thorough and complete than could possibly be developed under this proj- ect. In addition, OGC is considering and is likely to recom- mend incorporating the relevant portions of ISO 19133 as part of GML, and is likely to maintain its test suites as GML evolves. Therefore, it was determined that the TransXML project should not develop redundant validation software. Developers of future TransXML schema should make use of the OGC test suites for schema validation. The GML application schema validator (Version 2.1.2) checks the schema’s validity against Version 1.0 of the W3C XML Schema specification and Version 2.1.2 of the OGC GML rules. The schema must be available on a web server via a HTTP URL. The following checks are included in the validator: • All feature type definitions must extend xmlns(gml=http:// www.opengis.net/gml)AbstractFeatureType or form a com- plex type that extends that type; • A GML feature definition must not have a direct child ele- ment that derives from xmlns(gml=http://www.opengis. net/gml)gml:AbstractFeatureType; • A GML feature definition must not have a direct child ele- ment that derives from xmlns(gml=http://www.opengis.net/ gml)gml:AbstractGeometryType; and • The schemas must define the schemaLocation for all import and include statements that are resolvable from the source schema URL. The OGC test suite also provides a GML instance document validator. This validator checks a GML instance document against the GML 2.1.2 schemas and against the application 37

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

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

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

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

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

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

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

Next: Section 6 - Future Stewardship of TransXML »
TransXML: XML Schemas for Exchange of Transportation Data Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's National Cooperative Highway Research Program (NCHRP) Report 576, TransXML: XML Schemas for Exchange of Transportation Data examines a proposed common framework for exchange of transportation data in eXtensible Markup Language, known as TransXML. The framework is designed to be used for developing, validating, disseminating, and extending current and future schemas. The report also explores the benefits that might be achieved by the adoption and expansion of TransXML, and highlights efforts designed to help ensure its success.

NCHRP Report 576 Appendices include the following:

Appendix A - Detailed Review of XML Schema

Appendix B - Geographic Markup Language (GML) Experiment Summary Report

Appendix C - Unified Modeling Language (UML) Models in pdf format

Appendix D - Unified Modeling Language (UML) Models in xmi format

Appendix E - XML Schema Files

Appendix F - Sample Applications

A link to the download site for the appendices and to instructions on burning an .ISO CD-ROM are below.

Help on Burning an .ISO CD-ROM Image

Download the NCHRP Report 576 Appendices Image

(Warning: This file is large and may take some time to download)

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!