Foreword
Designing Geodatabases for Transportation is an outstanding contribution to the ESRI thematic geodatabase design series of “best practices.” This transportation domain data model achieves the two primary goals of the series:
• Provide best-practice templates for implementing geodatabases for transportation applications.
• Communicate a practical database-design process for geographic information systems for transportation (GIS-T).
Al Butler’s contribution of the transportation application domain data model provides guidance on “what really works.” He shares his knowledge of transportation, GIS, and database management with the GIS-T user and developer communities.
In the early 1990s, Al Butler and I were critiquing each other’s early efforts to create GIS-T data models. Then we decided to collaborate to achieve our common vision of a GIS-T data model that could accommodate:
• Multiple networks, some of which might include forest roads, alleys, or private roads.
• Multiple cartographic representations necessitated by differences in scale and source.
• Multimodal transportation systems.
• Multiple segmentations for various applications.
• Multiple linear referencing systems for infrastructure management and dynamic routing applications.
• A common data model to support multiple users, including facility managers and fleet managers, and multiple applications, ranging from long-range planning to real-time operations.
• A geodatabase approach for transaction-based updating and maintenance and a reduced reliance on versioning.
Our collaborative effort resulted in an enterprise GIS-T data model using E-R diagrams. However, this effort was perceived narrowly as a state department of transportation and highway relational representation. Meanwhile, higher-profile efforts, such as the Federal Geographic Data Committee (FGDC), National Cooperative Highway Research Program (NCHRP) 20-27, Unified Network for Transportation (UNETRANS), and Geospatial One-Stop utilized high-level object-oriented data-modeling approaches. These approaches were not adopted because they required a single authority to dictate a single network, single geometry, or single feature ID schema. Although Al and I participated in these efforts and tried to influence their design, none fulfilled our vision to incorporate all of the above-listed objectives. In addition, the high-level, object-oriented approach allowed ambiguities that created problems at the implementation stage.
While I have faded into retirement, Al has persisted and has shown the way to achieve the vision. His resulting book should be viewed as a manual of best practices that will provide guidance, not serve as a prescription. Most significantly, he calls for separating the editing geodatabase
