Traffic engineering signals geodatabase: design and implementation.
Baltimore County, Maryland has begun developing large-scale geographic information systems (GIS) databases to support a wide variety of agency specific applications. The County implemented a work order/infrastructure management system (WMS) in the Department of Public Works in the Bureau of Utilities with the intention of integrating the system into other Bureaus over time. The application includes a dynamic link to GIS that allows for spatially enabling of business processes such as mapping calls for service, analyzing workload and real-time assessment of cause-and-effect service issues. The second Bureau to implement the WMS will be the Bureau of Traffic Engineering and Transportation Planning with the main purpose being to improve maintenance workload prioritization and coordination. In preparation for the implementation of the WMS in Traffic Engineering, the Business Case was developed and substantiated for several infrastructure asset databases: signs, signals, calming devices, and striping. Since the implementation of the WMS was 18-24 months away and funding was available for database compilation, it was determined that the County would initiate projects to create the GIS databases for traffic signals and calming devices. The GIS databases would provide the ability to introduce Bureau personnel to GIS while filling the void for spatial data due to the limited knowledge of existing asset locations.
Baltimore County has a mature enterprise GIS including planimetric, topographic, cadastral, orthophotography and street centerline databases. The County's GIS databases are maintained as highly normalized geodatabases stored in ArcSDE in an Oracle database. The County has made a significant investment in funding and resources to modernize these data and actively works with the agencies and department to design and compile or redesign and recompile agency specific data. A key reason for the County's success at modernizing their databases stems from the use of a deliberate system development life cycle (SDLC) methodology to facilitate and coordinate the project activities. The SDLC process places the emphasis on requirements and design documentation rather simply a "build it and they will come" mentality. With established processes to define requirements and prototype design, the data developed for GIS will be fully integrated into the WMS upon its availability.
Baltimore County has several teams of contractors available for tasking through open-end contracts. This project was initiated by issuing a Request for Scope of Work to these pre-qualified contractors. The contractors responded with a scope of work documenting their understanding of the project, technical methodology for performing the work, resumes of staff to be assigned, references demonstrating experience designing and building similar databases, and a cost proposal. The emphasis on selection was to engage the services of the best-qualified contractor for this project to work with the GIS Unit and the agency to design, build and populate the database.
Critical to the success of the project is the composition of the project team. The team members must possess the knowledge and skills to guarantee success of the project. The Office of Information Technology, GIS Unit works closely with the agency and contractor during all phases of the project. The GIS Unit provides project management, database design/ administration and quality assurance/quality control services. The agency provided the subject matter experts and access to countless years of experience of the Bureau's engineers and engineering associates. Additionally, the Department of Public Works allocated their GIS Program Manager to bring his experience working with Public Works organizations to the project. The contractor's team was complementary to both the GIS Unit's and agencies with their resources assigned to the project.
Once the project team was assembled, a kick off meeting was executed to review the scope of work, document the communication methods and to finalize the project schedule baseline. In the case of this project, the scope would be further defined once the requirements and design were completed. The scope included the identification of database requirements, designing the geodatabase, collecting the asset data and acquiring photo images in the field, performing quality control, executing tests of the geodatabase using test cases developed during requirements and design, and delivery of final accepted data and lastly development of a fully documented and illustrated Maintenance Plan.
REQUIREMENTS AND DESIGN PROCESS
Defining the scope for the database feature and object classes presented an interesting challenge to the project team. A standard practice in the County is to take advantage of available resources and information from our peers. An attempt was made to determine best practices for developing traffic signal geodatabases; unfortunately there was little information available. Due to the lack of available information or references, the project team looked inward to pull from the expertise of the team. As the requirements were articulated and documented, it was not readily apparent what assets would be represented using feature classes or object information tables. While the number of signaled intersections was not excessive, approximately 350 maintained by the Bureau and 750 overall, careful considerations of what features to be mapped was an important consideration once the database moved into maintenance. (The difference in the number of intersections is due to the number of State maintained signals. The County elected not to capture and maintain the detailed asset information for these signals, instead just representing the location with a feature for reference.) After an exhaustive discussion on the content of the database, a list of physical features and their attributes were identified and documented. This list would undergo refinement during the design and pilot phases of the project.
Ultimately, the requirements for the features classes became apparent. Some physical features, such as video and red light cameras were identified as object classes referenced to their support feature rather than being a separate physical object. Conversely, the traffic control location is a point location that does not represent an actual physical feature, but rather a generalization of the signaled intersection representing the group of associated features and their attributes.
The design process was performed using iterative design and review cycles to be able to visualize the database with sample data to verify and validate the requirements. Each iteration of the design prototype was delivered as a personal geodatabase including sample data. The sample data was critical to allow the agency to visualize the data, ensure conformance to the requirements and get buy-in for the design. The entire Design Team executed the test plan for each prototype delivery and documented all issues and revision recommendations for the vendor to address during the subsequent iteration. Once the physical design was close to being finalized, the agency subject matter experts and the technical Design Team participated in a workshop to build consensus and acceptance for the geodatabase design solution. Upon reaching group consensus, the Design documentation and final data model were formally approved by the project team authorizing the vendor to proceed into database development.
Feature Class Design Decisions
The geodatabase design configured to model the traffic signal intersections included a mixture of feature classes and object classes. The Design Team modeled most of the primary traffic signal intersection assets with a point feature class, while an object class represented the remaining intersection appurtenances. The primary entity of the geodatabase design is the Traffic Control Location. This point feature class represents a generalization of the entire signaled intersection and provides the necessary building block to logically associate all the appurtenances at the intersection. The physical intersection assets represented with a point feature class included poles, handboxes and cabinets. A series of relationship classes were included to relate the pole, handbox and cabinet feature classes to the traffic control location feature class.
Object Class and Attribute Design Decisions
The object classes designed to capture detailed asset information include the traffic signal, video camera, and red light camera tables. The main reason the Design Team chose to use an object class to model these features rather than a point feature class is because both the camera and signal structures are mounted on a pole; therefore it was appropriate to store the information in a related table. An object class was also used to store the traffic signal bulb information for each signal, including details about bulb color and size configurations.
The attribute fields were established for both the feature and object classes to ensure complete information was captured for all entities. The Design Team identified the proper field type, length and name for all the attribute fields. To ensure data entry consistency, a set of configured domains were added to the attribute fields where appropriate.
Each feature class and object class has been developed with a primary key, which is a unique identifier field. The primary key number syntax was developed by the Design Team to be simple and easy to maintain. The team purposefully avoided using intelligent primary keys when modeling the geodatabase and developing the documentation. The primary key syntax was developed using the engineering drawing number as the foundation followed by a series of unique numbers. The primary key fields were strategically placed in related tables as a foreign key to support the associations between entities.
Relationship Design Decisions
The relationship classes are designed to relate two entities based on the primary key and foreign key fields. The following table identifies the primary relationships modeled by the relationship classes in the database design that depict the established logical associations and the cardinality.
The physical diagram of the entities, attributes and relationships assisted the Design Team with the understanding of how the logical model was transformed into a physical database design to support the defined requirements for the geodatabase. Below is an example of the physical model depicting the association between the asset feature classes and the traffic control location.
[FIGURE 1 OMITTED]
In addition to the primary object classes used to represent physical appurtenances on the poles at the intersection, a secondary set of related object classes were established to store information about the Traffic Control Location feature class.
The related Object Classes include:
* Intersection Photos
* Intersection Drawings
* Intersection Location Names
* BGE Address Listings
* County Street Centerline ID
* Feature Lineage Tables
The intersection photos table stores the links to the digital images for each intersection photograph. The intersections photo object class stores the path to the photo in a text field, along with the name of the image file. Typically, each signaled intersection has a photograph for each approaching travel direction, such as northbound, southbound, eastbound, westbound (where applicable). The images can be accessed as a hyperlink using the Identify Tool in ArcMap.
The intersection drawings table stores links to the digital images of the engineering drawings. The location names table stores the general reference name for the signaled intersection, which is usually a combination of the primary and secondary (bisecting) street names.
The BGE Address and County Street Centerline identifier table stores specific detailed information that is related to the Traffic Control Location. The BGE address is the billing reference for the electricity account used to power the intersection, while the street centerline identified information relates to the associated centerline the signaled intersection is located.
[FIGURE 2 OMITTED]
Finally, all feature classes were designed to have an associated table to store lineage, transactional history about the legacy of the feature and attributes. The lineage tables, which exist for all feature classes, store key attribute information for editor name, source, method, technology, authority and description along with capturing the edit date.
The database was built by performing data collection in the field using mapping grade global positioning system (GPS) units. For this project, the contractor used Trimble GeoXT units that proved adequate for this task. The units are handheld and easy to use with a well-defined data collection data dictionary. The data was collected in 10 geographic regions referred to as sessions. Each feature captured with the GPS unit was collected with a minimum of 30 seconds of collection time per point. The GPS session parameters were optimized to ensure adequate satellite coverage and a maximum Position Dilution of Precision (PDOP) of 5. The contractor was able to load the County's edge-of-pavement data into the GeoXT's to aid in field-based quality control. Along with collecting the data points, the contractor also captured digital photographs in each travel direction for all intersections. The photos are linked as an object class for future reference and were a valuable resource in the County's quality control process.
Several times during the field collection process, the teams were not allowed to enter restricted locations to collect the signal data. To manage this limitation, the County chose to contact the restricted facilities to gain access. If access was still denied, the detailed inventory data was omitted from the database and only the Traffic Control Location feature was captured to represent the intersection.
The field collection process was conducted over a period of six months. During this time, the vendor encountered several types of inclement weather that canceled field activities. The project team learned the lesson that for all future field collection projects, a contingency of time must be planned into the schedule to allow the team to manage the delays in the collection process. The additional slack in the project schedule will enable the project team to account for delays due to nature.
After each field data collection session was completed, the data was post-processed in the office to further enhance the accuracy of the data. Differential correction was performed on the raw GPS files. The data was "verified" against the County's existing large-scale planimetric database and orthophotography. The Traffic Control Locations were added using heads-up digitizing for the State maintained intersections. Heads-up digitizing from construction drawings was also performed to add hidden features that could not located in the field. Once the database was scrubbed for consistency and the initial quality control was completed, additional attributes were added to create hyperlinks to the photographs.
[FIGURE 3 OMITTED]
Upon delivery of the data by the Contractor, the County subjected the data to a rigorous quality control program. OIT's GIS Unit performed a high level review to verify attribute completeness. The database was then forwarded to Traffic Engineering and the subject matter experts. Traffic Engineering reviewed the data for both spatial and attribute accuracy and completeness. Traffic Engineering used the field photographs, construction drawing and site visits to assist in their quality control review. Traffic Engineering was responsible for itemizing the discrepancies for correction by the contractor. Before shipping the data to the Contractor, the GIS Unit reviewed the discrepancy calls to make sure they adhered to the standard discrepancy format.
Developing geodatabases for the eventual use in a work order/infrastructure management system requires deliberate and detailed requirements gathering. Participation in requirements and design phases by the subject matter experts is paramount to the eventual success of the project. Preconceived notions on what should be mapped can be misleading and can lead to false starts in the development process. Using iterative prototypes in the design phase can save significant amount of time in the development phase of the project. The use of "intelligent" keys is unnecessary in a geodatabase and probably should be avoided since it is hard to manage without a maintenance application. Careful planning is necessary to gain access to restricted areas during field data collection. Project scheduling for field projects introduces new challenges when weather and satellite availability can hinder production. Project Scheduling needs to be flexible and not constrained with fixed dates on deliverables.
Key Asset Relationships Defined by the Relationship Classes A Traffic Control Location can have zero to many associated Poles, Cabinets and Handboxes. A Pole, Cabinet and Handbox can be associated to one and only one Traffic Control Location. A Pole can be associated to zero to many Traffic Signals, Red Light Cameras and Video Cameras. A Traffic Signal, Red Light Camera and Video Camera can be associated to one and only one Pole. A Traffic Signal can be associated to one to many Signal Details (bulbs). A Signal Detail (bulb) can be associated to one and only one Traffic Signal.
Douglas M. Adams
Office of Information Technology
Towson, MD 21204
410.887.2289, 410.821.8024, firstname.lastname@example.org
Jeffrey A. Tirschman
Office of Information Technology
Towson, MD 21204
410.887.2553, 410.821.8024, email@example.com
TABLE 1--Physical Feature Designations Feature Classes Traffic Control Location Pole Cabinet Handbox Object Classes Traffic Signal Video Camera Red Light Camera
|Printer friendly Cite/link Email Feedback|
|Author:||Adams, Douglas M.; Tirschman, Jeffrey A.|
|Publication:||Urban and Regional Information Systems Association Annual Conference Proceedings|
|Date:||Jan 1, 2006|
|Previous Article:||Human migration analysis of the Austin-round rock and San Antonio, Texas, economic areas.|
|Next Article:||Traffic controls geodatabase: requirements/design.|