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

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.

56 Comments from the TransXML community were sought on the UML models through August 30, 2005, and on the TransXML schemas through December 31, 2005. Comments received beyond those dates could not be incorporated into schema and sample applications developed in the course of this project. This additional feedback has been collected in this appendix so that it can be addressed in future TransXML development. G.1 Safety Business Area Additional Comments from Reviewer #1 The existing schema need to be supplemented in the area of site information. There is little allowance for informa- tion that is needed for accident reconstruction and safety analysis. The length, location, and orientation of skid marks are crucial to estimating the speed of a vehicle and the driver’s actions at the time of the accident. The type of any barrier that was struck is essential to studies aimed at evaluating the performance of those barriers. While acci- dent reports may be available, a mechanism is needed to sort to the ones that involve the specific barrier system of concern. There is still a lot to be studied in regard to acceptable widths of clear zones and clear areas. Accident data is key to those studies. The schema needs to allow the lateral travel of errant vehicles to be documented, as well as the sideslopes of the clear area. Quality of the clear areas is also an open question, as higher center of gravity vehicles are less likely to perform well on sideslopes that have been considered acceptable for traditional personal vehicles. The schema needs to allow recording of both sideslopes and vehicle rollover information. The amount of damage to a barrier system is a key piece of the accident record and also valuable to the maintenance effort to repair that guide rail. The safety schema should include these and other data about the physical condition of the roadside and the evidence of the crash dynamics. The TransXML effort should develop draft schema additions for these needs rather than just passing on the suggestion to NHTSA. Additional Comments from Reviewer #2 The comments below refer to the UML models docu- mented in the section labeled “Highway Information Safety Analysis Package” which can be found on pages 73 through 100 of the UML Model Appendix to this report. • Page 83, 7.2.23: urbanRural (Area Type) could be expanded to include suburban With respect to Intersections: • The actual geometry of an intersection cannot be determined/reconstructed from the data elements in the schema (e.g., skew is not represented). • The “Intersection” is a sub-element of “RoadLocation” and has two attributes named “locationReferenceMinor Road” and the “minorRoadName.” This implies that the road that is identified by “RoadLocation” is the major road for all of its intersections, which is not necessarily true. The model cannot represent situations in which the roadway under analysis is the minor road at an inter- section. This could be acceptable if an assumption is added to the model that an intersection is counted as a sub-element for a roadway only if the roadway is the major road. • “Corner” data are not in the model. • “Turn Speeds” are not in the model. A P P E N D I X G Additional Feedback on Schemas and UML Models

With respect to Roadway Segments: • The following elements used in IHSDM are not explicitly modeled: – Roadside hazard rating; – Ditches (defined implicitly via the cross-section elements); – Obstruction offset; – Shoulder width and slope; – Curve widening; – Bridge presence/width; – Speeds: design and 85th percentile; and – Percent RVs. • “Average lane width” is provided (which includes the aux- iliary lane width), but the width of individual lanes cannot be defined. • Turn lanes are not explicitly defined, except for TWLTLs. Under the Auxiliary Lane Type code list, there are “accelerationLane” and “decelerationLane”—are these meant to represent turn lanes? • Driveway Density is provided, but the locations of indi- vidual drives cannot be specified (which might be needed for future IHSDM/HSM models). • It is unclear whether more than one auxiliary lane can be modeled per direction. Also the relative placement of the auxiliary lane with respect to the thru lanes cannot be modeled. • Only one shoulder type per direction can be modeled. Also, the “Composite” shoulder type that is included in the schema was eliminated from the IHSDM roadway model. • The “Bikeway” attribute for each direction of a Road Segment seems to duplicate the “bicycleLane” attribute in “Auxiliary Lane Type.” • Curvature, superelevation, and grade data duplicate ele- ments in the Geometric Roadway Design section. Additional Comments from Reviewer #3 The developed Safety Schema do not cover crash dynamics or roadside geometry concerns in any place close to the level of detail that I was hoping for. My major motivation far par- ticipating was to ensure that the developed schema adequately addressed sideslopes, backslopes, guide rail types, terminal and attenuator types, etc. That did not happen. 57 G.2 Survey/Design Business Area Additional Comments from Reviewer #1 The comments below refer to the UML models docu- mented in the section labeled “Geometric Roadway Design, 2nd Draft,” which can be found on pages 172 through 254 of the UML Model Appendix to this report. The page number references shown below refer to the numbering scheme used within that section of the appendix, not to the page numbers of the appendix itself. • Intersections are not modeled (but intersections are cov- ered in the “Highway Information Safety Analysis (HISA) Package”). • Page 38, “Line,” “dir[0. .1]” attribute: How is the direction of the line defined (e.g., using N/S/E/W, azimuth, etc.)? • Page 41, “Spiral,” “Recommendation,” line 7: Should the references to “begin length” and “end length” of a spiral instead be to “begin radius” and “end radius?” • Page 55, Superelevation>Carriage Way>Lane: Lane width is entered indirectly via offsets, but there does not appear to be a way to identify lane type (thru, turn, climbing, passing, etc.). • Page 55, The proposed Superelevation model cannot model a break in cross-slope within a lane. (Not sure if this is important.) • Page 56, “Superelevation”: For “standard AASHTO” tran- sitions, it appears that the “beginStation” and “endStation” attributes are redundant with the Critical Transition sta- tions related to Transition Types “entryNormalCrown” and “exitNormalCrown.” • Page 59, “Transition Type”: The “specialTransition” attri- bute is defined as “Any special transition location.” It is unclear whether the type (e.g., beginning of alignment) is to be specified for the transition location, or just labeled as “special transition” regardless of type? • Page 64, “CrossSect”: What does the “name” of a cross section refer to? • Page 69, “DesignCrossSectSurf ”: What does “typical width” refer to? • Taper locations (e.g., begin/end of turn-lane taper) are not explicitly modeled. However, they could be modeled using cross-sections, if the “critical” points are captured. • Shoulder width and slope are not modeled. Only one shoulder section can be modeled per side.