Click for next page ( 23

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 22
23 develop and gain stakeholder agreement given the work that holder communities (pavement designers and traffic engi- has already been accomplished by the previous efforts identi- neers), and should be addressed once the initial set of schemas fied in Section 3. The selections also took into account the fact are established. that several schema development efforts are ongoing (or The first three subprocesses have been addressed by the planned) within other organizations (e.g., LandXML), and LandXML schema. The following discussion identifies gaps therefore any improvements would need to be pursued in in the existing schema that were considered within the scope coordination with these other organizations. of TransXML (in coordination with The priority business processes identified in this section are the basis for the selection of the initial set of schemas that Geometric Design/Surface Model were developed for TransXML. Information (LandXML) The most significant information exchanged during design 4.2 Roadway Survey/Design and carried forward into subsequent life-cycle phases is the In order to explore schema opportunities in the roadway geometric design of the roadway. Beginning with preliminary survey/design business area, the research team drew upon a design, the roadway design evolves through the refinement of business process modeling exercise conducted as part of a the horizontal and vertical alignments and the addition of prior project (conducted by Bentley Systems, Inc. for the pavement section, superelevation, cross sections, and geo- Minnesota Department of Transportation [MnDOT]). This metrics. This is an iterative process based upon project con- project produced a set of data flow diagrams which depict the straints, codes and other regulations, budget, and time. It is preliminary and detailed design of roadways and related done in conjunction with other disciplines which impact or structures. The diagrams show the design activities (func- are impacted by the design, including but not limited to right- tions) performed as well as the data that is exchanged between of-way, drainage, utility, hydraulic, traffic, environmental, these functions. and aesthetic concerns. XML can provide a method of shar- The data flow diagrams were reviewed from a TransXML ing the roadway design as it evolves during the design process. perspective. Each data flow was evaluated to determine if it It can also provide the basis for capturing as-built informa- is an appropriate candidate for a TransXML schema. The tion as the roadway is actually constructed. This information following subprocesses emerged as candidates for XML can then be utilized during the maintenance and operation of schema: the roadway. As each member of the design team develops a design solu- Sharing of roadway geometric design information (hori- tion for their particular part of a project (drainage, roadway, zontal and vertical alignments, pavement section, super- bridge, traffic), they are dependent upon and have influence elevation, cross sections, geometrics) across design team upon the designers of the other parts of the project. For members as it evolves throughout the design process; example, a roadway designer begins with a rough alignment Utilizing information produced in the design phase as the from the preliminary design phase. As this alignment is refined, basis for developing as-built information from the con- the results need to be communicated with the hydraulics engi- struction phase, and then making the as-built information neer to complete the site drainage; with the bridge engineer available for use during the maintenance and operation to develop the detailed bridge geometry; with the traffic engi- phase; neer to begin staged construction planning; and eventually Sharing of surface models across design, survey and con- with the surveyors for stake out (see Figure 2). struction, including use of this information for automated The information being exchanged which constitutes the machine control; roadway design includes the horizontal and vertical alignment, Transferring pay item information in the design phase for cross sections, superelevation, and geometric information. further development in the construction phase; and This area has been a focus for LandXML, which is already Transferring GIS-based planning information on area fea- in widespread use, supported by and yielding tures into CAD-based design software. substantial benefits. However, there are areas of LandXML which can be improved: These subprocesses cover all of the specific topic areas listed in Table 1 under the Roadway Survey/Design business Provide a semantic model and documentation in order to area, with the exception of Pavement Design and Traffic and increase clarity, as certain areas are open for interpretation ITS Design (Right-of-Way may be partially addressed by by users, thereby increasing the usefulness of the schema LandXML, and the GIS-into-CAD area). These two topic for interoperability. For one-off data transfers between two areas are fairly large in scope, and involve distinct stake- specific processes, this interpretation is acceptable as long

OCR for page 22
24 Create Detailed Roadway Design Bridge Design Create Detailed Drainage Design Roadway Design Create Detailed Coordinate Roadway Design Roadway Design Detailed Design Roadway Design Create Detailed Design of Other Structures Create Detailed Roadway Design Traffic System Design Figure 2. Data flow diagram: coordinate detailed design. as the two processes make the same assumptions. As the NCHRP 20-64 provided a mechanism for developing techni- use of the schema broadens (e.g., extending into construc- cal content for proposed improvements that were submitted tion and maintenance and operation), the ambiguities can to for consideration. become more problematic. Support the feature-based approach of most spatial stan- Contract Pay Items dards, including the ISO TC211 191xx geospatial stan- dards, OGC specifications including GML, and Geospatial Contract pay items span the design and construction busi- One-Stop. LandXML supports the CAD notion that geo- ness areas. Pay items are the basis for estimating the cost of metric representation is paramount and that attributes or the project, comparing alternative design solutions, obtain- feature properties can be hung off of these, almost as an ing a contractor to construct the roadway, assessing the afterthought. An enterprise view would be better served by progress of the construction, providing the basis for partial an object or feature-based approach, where the geometric (progress) payments during construction, billing the work representation is merely one more attribute of a feature. completed, and potentially feeding maintenance and oper- This would accommodate multiple geometric representa- ation systems such as roadway inventory and asset man- tions for the same road feature, such as a 1:24,000 scale GIS agement. Though contract pay items predominate in the linestring approximation and a 1=50 engineering true construction phase, they begin during design and are there- curve representation. fore proposed as a design business area schema which can Expand to include general purpose topological primitive evolve into a construction schema as more information is constructs, i.e., link-node linear networks. Currently LandXML supports linear topology with feature to feature added to the pay items. relationships between pipes and structures. TransXML Pay items provide the basis for estimating, bidding, and needs to support other linear networks, such as the road- construction management. The design engineer determines way network itself. what pay items make up the project and determines how Provide additional enhancements (e.g., the ability to break much of each pay item will be required to complete the job. by lane for superelevation, the need to transition super- This is based on a standard set of contract pay items with pre- elevation nonlinearly, and the featurization at individual defined units of measurement. The pay items and their quan- points of cross sections). tities are then passed to the estimator to predict the cost of the project. Often the items and quantities are included in the As noted above, because LandXML is already widely used, contract documents for the project (see Figure 3). and there is an established mechanism for improving this The information being exchanged includes the standard schema, the NCHRP 20-64 project did not pursue the above contract pay items with their units of measure, and the improvements independently from Rather, quantities of each that will be used on this project. The

OCR for page 22
25 Develop Detailed Contract Quantities Design Estimate Standard Determine Create Contract Contract Pay Items Contract Quantities Quantities Final Plans Pay Items Pay Items, Design Quantities Project Design Legend External Business Data Flow Data Store Entity Process Figure 3. Data flow diagram: determine quantities. aecXML infrastructure effort produced a good first cut at Area Feature Support such a schema, which has been implemented in product at the MnDOT. However, this schema does not completely Instead of starting with a clean sheet of paper, it would be meet the needs presented here because it doesn't address advantageous if designers could capitalize on the information quantities or prices. A schema that provides a single, con- collected during the planning phase. Much of this informa- sistent list of pay items on a project, with quantities and tion is available with GIS software which is often incompati- prices would better support the needs of the designer, esti- ble with engineering design software. mator, plans developer, contract administrator, contractor, A significant number of data flows involve polygonal data, and inspector. including environmental areas, soils, wetlands, land use, flood The design-to-construction process emerged as a high- plains, site improvement areas, right-of-way, and cadastral priority candidate for TransXML. The model and resultant information. Though less significant than the previous two XML schema developed here were further augmented within schema opportunities, it does represent a significant gap in the construction business area in support of pay item data the design area. It also is exemplary of the gap between GIS exchange for construction phase activities. and CAD, wherein traditional systems of each type have pro- The aecXML infrastructure break out was done under vided significant frustration for users in their inability to the IAI aecXML Domain Committee umbrella, but it was exchange data. It also is an opportunity for incorporating the largely an independent effort by the aecXML Infrastructure common geometry model adopted by the three leading inter- Working Group. While the IAI aecXML effort is still active, national GIS standards. the aecXML Infrastructure Working Group is now dor- An example of a design activity requiring such a data mant. Given that the focus of the larger aecXML effort exchange is creating preliminary design (see Figure 4). has been on buildings which have substantially different LandXML does support a survey view of a land parcel ele- requirements than roadway projects, it was appropriate for ment. However, its geometry does not provide support for NCHRP 20-64 to take on further enhancements to this holes and islands and constraints such as closure, nonover- schema. lapping and nonintersecting rings as specified in other spatial