TransXML FAQ

TransXML is a family of data exchange formats (expressed as W3C-compliant XML schemas) that will make it easier for transportation agencies to share information within and across the different stages of the transportation facility life cycle - spanning planning, design, construction, maintenance and operations. XML is being used in a variety of other industries to enable data sharing. However, XML in and of itself is not a “silver bullet” – its value depends on getting agreement on data exchange formats from data owners, data users and software vendors. TransXML responds to the urgent need for the transportation community to work together on common data exchange formats.

The TransXML project is being undertaken to save agencies money. Currently, countless hours are wasted re-entering or re-creating information that already exists in electronic form. Data quality suffers in the process, and even more resources must be invested to ensure that data are correct with each transfer. Some transportation agencies have already recognized the value of XML, and are developing their own schema to facilitate data exchange across applications. A collective, broad-based approach to this problem would reduce the need for multiple similar efforts of this nature. More importantly, it would enable and encourage software vendors to build in standard data import and export features consistent with the agreed-upon formats. That will give agencies more choices, and will reduce the costs of configuring and implementing new applications. TransXML will also provide a way for agencies to archive their valuable data in a text format that is human-readable and independent from the software used to store it.

The bottom line is that TransXML will allow agencies to have more control over their data, and to get more value out of it over the long haul.

2. What is the scope and schedule of the project?

The initial TransXML project focused on schema in four transportation business areas: 1) Survey/Roadway Design, 2) Transportation Construction/Materials, 3) Highway Bridge Structures, and 4) Transportation Safety. XML Schema were developed within each of these areas, along with sample applications to demonstrate how the schema can be used. NCHRP 20-64 concluded in September, 2006. The project team has recommended that US DOT take over as a permanent steward for the TransXML effort; as of this writing (September, 2006) AASHTO is working to identify an interim steward.

3. How exactly would people use TransXML?

Here is the vision for the initial set of TransXML schema – many more applications are possible in the future:

· Construction Bidding – A transportation agency would export a TransXML bid package document from its project development or bid preparation database and make this available electronically on its web site. Contractors would import these documents directly into their bid preparation systems.

· Construction Payments - A construction inspector would export a TransXML construction progress document each day for their project from the field-based data collection device used to track pay item partial quantities placed. This document would be imported into software used to produce construction progress reports and into software used to process contractor payments. Separate TransXML materials testing documents would be produced from field construction tracking software, and exchanged with laboratory personnel and the project engineer.

· Construction Project Status – Agency construction management systems would periodically export project status information as a TransXML construction project status document. This document would be used to produce a variety of standard reports suitable for printing, publishing on agency construction status or traffic information web pages, or submittal to other organizations (e.g. utilities).

· Safety – A state DOT would export a TransXML highway inventory safety analysis document from highway inventory databases, and import that into safety analysis software (e.g. FHWA’s SafetyAnalyst program currently under development) to identify sites with promise for safety improvement, or to analyze potential safety countermeasures.

· Safety – State or local crash record data collection systems would produce TransXML crash documents that could then be validated and imported into crash data repositories. Crash data repositories would produce TransXML crash documents in response to standard queries, which could then be published in a variety of formats (e.g. as HTML for web display; as printed reports, etc.)

· Design – Roadway designers would export a TransXML area features document from their GIS dataset containing information on area features such as wetlands, flood plains, and right-of-way. This document would be imported into the roadway CAD software to serve as a backdrop to the design drawing.

· Design – Roadway designers would export a TransXML design pay item document from their design software package for a completed or in-progress design, and then import this document into their estimation package to produce a preliminary cost estimate for the project.

· Bridge Structures – Bridge designers would export bridge structure information from the AASHTOWare Virtis package, and then import that information into other bridge analysis packages to provide verification of structural analysis computations.

4. Who is sponsoring development of TransXML?

The TransXML effort was launched as a research project under the auspices of the National Cooperative Highway Research Program (NCHRP). The American Association of State and Highway Transportation Officials (AASHTO) Subcommittee on Information Systems and the Transportation Research Board Information Systems and Technology committee were actively involved in initiating this project. The project was directed by a panel with representation from the Federal Highway Administration, AASHTO, state DOT’s, universities, and industry.

Part of the project’s scope was to recommend a future model for continuing stewardship and further development of TransXML. The project team has recommended that US DOT take over as a permanent steward for the TransXML effort; as of this writing (September, 2006) AASHTO is working to identify an interim steward.

5. Who is developing TransXML?

The research team was led by Cambridge Systematics, Inc., with Bentley Systems Inc., Info Tech Inc., Michael Baker Inc., and Charles Campbell. These firms have active involvement and commitment to open data standards in transportation. They also collectively represent a number of widely used transportation software applications – AASHTOWare® Trns?port (construction management), Pontis (bridge management), Virtis/Opis (bridge design) software; and the Microstation, GeoPak, InRoads and MX design software.

6. What impact will TransXML have on LandXML – the already existing XML schema for survey and design information?

The TransXML research statement included roadway survey/design as one of the core business areas for development of XML schema. Prior to the TransXML project, LandXML had already been well established as a data exchange format for geometric roadway design information. Given the existing base of LandXML users, TransXML will not be duplicating what already exists in LandXML – LandXML’s geometric roadway design schema elements will be adopted by TransXML. However, research team members identified the need for refinements to the geometric roadway design information in LandXML in order to reduce current ambiguities and fill some gaps. Therefore, data models for geometric roadway design have been developed, building on the existing LandXML schema, and suggestions for enhancements to LandXML in future releases will be submitted for consideration by LandXML.org. (www.landxml.org).

7. What is GML and how does it relate to TransXML?

TransXML is an umbrella for a collection of related transportation data exchange formats. Each piece of TransXML will relate to a specific type of information that needs to be exchanged (e.g. construction status information, highway safety characteristics, bridge geometry), and new pieces can be added over time. However, the intent is that all of the parts of TransXML will be developed using a consistent framework. This framework will make sure that fundamental building blocks (like units of measure) are available and used in a standard fashion. It will also ensure that each part of TransXML follows a consistent set of stylistic rules. This is analogous to the use of standard coding conventions across a large software application development team, so that the resulting application is easier to maintain and enhance over time.

The most logical choice of a framework for TransXML was the Geography Markup Language or GML. GML is specifically designed to serve as a framework for domain-specific XML application schemas like TransXML. GML was selected as the framework for TransXML because it provides a well-designed set of rules for schema development, as well as an extensive set of primitive building blocks. It has broad and growing acceptance among GIS vendors and is an integral part of the Open Geospatial Consortium’s efforts to improve sharing of geospatial data as well as CAD-GIS interoperability. GML version 3.1 is now in the process of being adopted as an international software standard, ISO 19136. It implements many of the companion ISO TC211 (GIS) 191xx family of geospatial standards, including ISO 19109, Rules for Application Schema.

8. Does the decision to use GML mean that TransXML will only deal with spatial information?

No. Clearly GML’s ability to represent spatial information was viewed as an advantage given that TransXML is about transportation, which is fundamentally spatial in nature. However, many parts of the TransXML schemas (both the initial set and potential future ones) will not pertain to spatial information – for example, those related to the business view of transportation projects as opposed to the physical view. GML-based XML schemas can contain both spatial and non-spatial information. In GML, data elements that represent physical entities that can be located in space (like roads and bridges) are called “features”. Data elements that represent non geographically-based entities (like construction contractors or drivers) are designated as “objects”.

9. How will the adoption of GML affect TransXML’s ability to co-exist with existing non-GML-based XML Schema?

While having a consistent framework for TransXML is an important design choice, this choice applies only to new schema being developed for TransXML. The need to make the best use of available resources, and avoid further proliferation of duplicative data standards overrides the objective of strict consistency across TransXML schema. Existing XML schema relevant to the transportation community, particularly schema that have broad acceptance and are being actively maintained by another stewardship organization, will not be replaced by new, GML-compliant TransXML schema.

10. How do I get involved?

Go to www.transxml.com. Sign up as a participant in a working group for one of TransXML’s four business areas. Review the schemas and submit comments on the discussion forums. Offer your opinions on comments posted by others.

11. What can I expect to find on the website and how can I help?

The research team has posted many work products from the effort, including UML models, preliminary and revised schema, sample applications, and the project Final Report and Appendices. Please feel free to download, review, circulate and comment on the materials you find here.