Building a Baseball Stadium Using GIS

In March of 1997, work began on the New Pacific Northwest Baseball Park. At a cost of more than 415 million dollars, and an extremely restricted time schedule, the project would need efficiency, organization, hard work and a little luck to be completed on time. Presently (March 1998) the project is on schedule. Part of the reason for this is a system developed as part of this project, bringing together scheduling technology, document/contract management and (by June 1998) costing into an Arc View based GIS.

This GIS system has been a crucial player in the construction of the ballpark. The intent of this paper is to outline how this system was and is being created , its various components, and to illustrate some of the ways GIS is having an impact on the project.

Large construction projects, always logistically complex, can benefit substantially from a well-planned and well-designed data management program. Arc View GIS 3.0 is being used to coordinate the scheduling, planning and logistics in the construction of the New Pacific Northwest Baseball Park in Seattle, Washington. This project provides a good example of the importance of data management, retrieval and analysis, given the dozens of contractors working on this project, and the 'fast-track' nature of getting this 'small city' built by the early July, 1999 scheduled completion date. In addition, the use of Arc View GIS provides additional benefits for visualization, analysis and mapping of scheduling and logistical information in a unique way for this type of project.

My involvement in the stadium project started out as scheduler, working as a consultant for Walter and SCI Construction and Engineering, the main subcontractor to Hunt-Kiewit, the construction management organization. Developing a GIS was not what I was being paid to do, but the idea was intriguing enough to enough people that a test project was proposed to determine feasibility.

The test project took approximately one month to complete and as one might expect, very simple. It was more of a conceptual show-and-tell. However, reaction was very favorable, and the development of a GIS for construction of the stadium began. In fact, I had originally thought of using GIS just as a scheduling tool, but great ideas came from many people, incorporating not only scheduling, but document management, logistics, and soon, costing and cost impact analysis. Functional areas for the GIS are shown in figure 2.

A schematic of the GIS for the stadium project looks something like figure 3.

For each level the different elements were grouped by type (pile caps, grade beams, etc.). Elements of a given type were further refined, determined partially by design constraints, what could potentially be accomplished by one crew in a day and what the specification dictated. At the end of the refinement process for each element, Acitivity ID's were assigned. The element, for which the Activity ID is assigned, were given scheduling-specific attributes (duration, predecessors and successors, dates, etc.) and was also defined in the GIS. This process was simple and static for some elements (pile caps, columns, raker beams), complex and continuously changing for others (slabs on grade, grade beams, and main concourse decks). Table 1 illustrates the element types and their attributes.

The elements are loaded in Arc View as individual themes. When the scheduling portion of the GIS is invoked, the user can define which elements (themes) will be displayed and if any filtering (via a query) performed. An illustration of this is shown in figure 5.

The Activity ID provides a means of relating Scheduling information (and in the future, costing information) to elements within Arc View (figure 6).

The result is a map (figure 7) showing (in this case) areas on schedule (blue) and problem areas (orange) and problem areas needing immediate attention (pink).

The ability to present data in this form has proved to be an invaluable asset in the scheduling of this project.

To date on the project, there have been more that 5000 requests for information (RFI). The majority of these involve a clarification concerning design. The scenario is this: The contractor or one of its subcontractors will request more information about the design of an element (say, a beam, shown as two different dimensions on the same drawing: which dimension is correct?). The question will be documented and sent to the architect or designer for clarification. The time difference between when that question was asked and when it is answered is very important in determining scheduling delays and potential cost overruns. Not only is the time delay important, but also the number of the RFI's generated.

Primavera Systems Expedition software was used to manage the RFI documents (as shown in figure 8). In Arc View the RFI's were represented as points and were input based upon their x,y location (along with level). The points were given a unique ID, and this would tie the Arc View point theme to the document management database.

Now we could query by attribute, but also spatially query by element. So performing a query such as, "Give me all the RFI's for pile caps pertaining to rebar", is accomplished by performing a database query for rebar, and 'clipping' that with the pile cap theme.

Figure 9 is one of the resulting maps developed illustrating the number of RFI's (to date for one level). The different colors for represent different types of RFI's.

Of greatest concern on the project is the determination of where the greatest time differentials exist between when the RFI was asked and when it was responded to and if there is some common factor involved in any of these kinds of delays. The GIS for the project has been a valuable tool for answering those concerns.

A separate part of the GIS is responsible for the storage and retrieval of As-built photographs. At various stage of construction for each element (or group of elements), status photos are taken with a digital camera. These photos are retrieved using a slightly modified version of Arc View's 'Hot-linking' capabilities, allowing the user to access a time series of photos or any status photo that exists for an element.

 This ability has benefited the project greatly, by building in a quality check on the work performed. This has been used to resolve disputes pertaining to design, quality of work, and even the location of individual elements!

Structural Steel polygons

Early on it was determined that there were global issues and drop-dead dates forcing the schedule. The most important of these concerned the placement of the Structural Steel. The structural steel would be erected for seating and would provide support for the track holding the retractable roof. We had to have certain combinations of elements finished prior to the steel arriving on site.

We needed a quick way to check how we were doing, so a structural steel polygon theme was created that was simply areas of the site with dates for structural steel placement. Avenue scripts were created to overlay the structural steel date polygons with the schedule theme, thus identifying potential trouble areas.

The ability to plan what could be cast-in-place and what could be cast elsewhere on site and placed by one or more of the four tower cranes on site was a logistically important task, and an extremely simple task for GIS. Elements (for instance, beams) were given a weight, and since they were polygons, Avenue scripts were created to compare the weight of the beam with the location of the placement by one of the cranes. If it was too great a load for the crane at that location, then it was cast-in-place. Many types of potential pre-cast elements were treated this way. Figures 10 and 11 illustrate the planning the placement of potential pre-cast beams and pre-cast double tees (to hold seating risers).

The Arc View extension 3D Analyst was used to incorporate survey as-built information and provide yet another way of visualization and analysis. Not only did using this provide a convenient repository for the survey information, but has aided in the planning of the placement of the structural steel that will hold the retractable roof.

A 3D analytical tool is being developed with all the scheduling, document management, logistics and (June, 1998) costing. This will allow for a visual 'walk-through' with point-and-click access to many types of analyses.

Another interesting, though for our purposes non-essential application, was taking the refusal depth data from the 1500 driven piles for supporting the foundation, creating a TIN 'refusal' surface 80 to 90 feet below grade.

Data collected in the field for amount of labor (hence cost) performed to build each element is being incorporated with data on the materials used for the same element and assigned the Activity ID from the schedule. The goal here is to tie the costs of building an element to not only the schedule, but to the document management database, and ultimately the GIS.

When this gets incorporated in late June, we'll be able to determine and display costing analyses in map form. It will show where the project was efficient and where it wasn't, as well as how money was spent and where. We'll be able to answer questions such as, "Did the efficiency of the project improve with time?" This will ultimately aid in bidding future projects, because it gives us a model of costs and efficiency as a function of time and space.

Another equally important reason to incorporate costing into the GIS, is that it gives us another way of analyzing cost impacts from schedule delays, and determining why those occurred.

When the GIS structure was being developed for this project, the question I often asked was, "Am I trying to use GIS where it is not applicable to use it?". The answer became obvious during a meeting held for all of the contractors mid-way through the development of the system. During the meeting many assumptions were made as to why the project seemed behind schedule. These opinions ranged from poor management, to insufficient labor , to problematic dewatering of the site. For the meeting I produced a map showing conclusively that the issue at the time was late rebar delivery based upon unanswered design questions. The result was what would have been a five hour meeting was turned into a one hour meeting.

In addition, a map gives everyone a visual aid for seeing where the project is heading and why. For example, 'Hot Spots' polygons were created to overlay with the schedule for a quick status of the project. This technique has greatly speeded consensus building and decision making, the key to implementing a successful plan of action.

I'm very grateful to the following individuals for their ideas and encouragement:
John Russell, Joe Schroeder and Calvin Gidlof of Walter and SCI Construction.

J. Patrick Moore
Senior Engineer/GIS Analyst
SAI
12204 NE 64th St. Kirkland, WA 98033
Phone: (425) 828-8998
Fax: (425) 803-0704
Stadium Tel: (206) 464-1717
email: patrickm@seanet.com