Introduction
• Building the agile geodatabase
Modes of travel can be quite different but all follow a conceptual structure consisting of an origin, a destination, a path between the two, and a conveyance to move along the path. Designing Geodatabases for Transportation tells how to design a geospatial information system to manage data about transportation facilities and services.
An enterprise geodatabase can help solve two common transportation challenges: the many origins, destinations, paths, and conveyances that may be present; and the need to specify locations along the facility. There is also the matter of facility suppliers usually being different from facility users. The facility user focuses on origins and destinations. The facility supplier is concerned about the many paths over which a conveyance travels and generally not about specific trips. A transportation agency provides the facilities to support travel. Shippers—those who have goods to deliver—define the origin and destination for their shipment. A shipping company supplies the conveyances and selects the paths to move the shipper’s goods from origin to destination. Each origin and destination must be accessible from a transport facility. A shipping company can select a path only where a corresponding facility exists. Railroads perhaps can be viewed as being both suppliers and users of transport capacity although some may operate over facilities they do not own.
Transport databases
Transportation data is often specific to the various modes of transport. Designing Geodatabases for Transportation addresses six modes: walking, bicycling, motor highways, public transit (buses and commuter rail), railroads, and navigable waterways.1 All six modes involve linear facilities supporting point-to-point travel for people and material goods. The nature of the facility supporting travel and the way it is used differs with each mode. Some facilities support multiple modes of travel. Highways and roads accommodate motor vehicles, pedestrians, and bicycles. Railroads support commuter trains, long-distance passenger travel, and freight movement. Ships travel navigable waterways that flow under highway and railroad bridges.
Points of modal connection are commonly known as terminals, depots, stations, stops, and crossings. The name “intersection” is usually applied to highways, but conceptually includes other points where facilities cross and interact, such as railroad switches, crossovers, and diamonds; rail-highway grade crossings; and limited-access highway interchanges. Transport systems also include places where facilities cross but do not intersect, such as at bridges, viaducts, and tunnels.
Geographic information systems (GIS) for transportation—GIS-T in industry shorthand—routinely deal with mode- and function-specific applications, each with its own geodatabase design. What is rare is a GIS-T geodatabase that goes beyond serving the needs of a single application. Such a geodatabase must accommodate the many segmentation schemes employed and the various linear and coordinate referencing systems available to show where the elements, conveyances, and characteristics of transportation systems are located. Designing Geodatabases for Transportation shows you how to construct such an enterprise multimodal geodatabase, although the ideas presented in this book can be implemented for a single mode.
A transportation geodatabase addresses concerns beyond facilities and the services that use them. For example, facility elements and characteristics are affected by projects and activities that construct, maintain, and remove elements of the transportation system. There are also traffic crashes, bus routes, train schedules, and shipping manifests to consider.
Transportation applications are much too diverse for this book to present you with a complete transportation database design. That task is up to you. ESRI has successfully worked with user groups to develop a number of industry-specific data models. That approach will not work with transportation, which lacks a single, all-encompassing view of the industry due to its diversity. Not only are there modal differences to consider, but there are also differences in detail and abstraction. A trucking company, a city public-works division, and a state department of transportation (DOT) all need data about highways, but for their own purposes that require them to adopt very different data models. Even within a single transport agency there may be several different application-specific data models.
What this book offers is a collection of ideas and geodatabase design components to help you construct a model that serves your agency and its unique set of applications. It shows you a variety of ways to handle a specific data need, describing the pros and cons of each choice. In this way, Designing Geodatabases for Transportation provides a cafeteria of design options rather than a fixed menu to solve the broad range of transportation spatial data requirements.
Data models
Geodatabase design is normally expressed through a data model, which is a graphical way of describing a database. A data model is essentially a set of construction plans for a database. Some data models are very conceptual, others extremely detailed. Fortunately, all data models use a few very simple symbols. You need no prior experience with data models or geodatabase design to understand and apply the suggestions in this book.
All geodatabases form a set of abstract representations of things in the real world. The process of abstraction is called modeling. You may geometrically represent linear transport facilities in your abstract geodatabase world as lines. In the real world, of course, transport facilities are areas, which may be less abstractly represented by polygons. Unfortunately, many of the analytical techniques you will want to employ, such as pathfinding, do not exist in the polygon world. This is not really a problem, though, because the central aspect of a linear transport facility is its linearity, so points and lines form the abstract world of most transport geodatabases.
Whether you formally draft a data model or not, one exists inside each geodatabase. It may also exist externally as a set of requirements, a list of class properties, or some other description of the geodatabase’s contents and structure. ESRI’s ArcGIS software comes with tools to produce a data model from an existing geodatabase. As geodatabases grow from supporting isolated workgroups to major portions of a complete enterprise, the complexity of geodatabase design normally increases in proportion to the number of data uses. Explicit data models and other documentation become more important as the scope of a geodatabase expands or it begins to serve a critical function within the organization. As a result, many organizations have invested significant resources into developing a good data model before moving forward with geodatabase development and migration projects. More comprehensive and ambitious projects seek to deploy at the enterprise level.
Building a good enterprise geodatabase starts with an enterprise data model. Accordingly, this book expands and enhances the previous ESRI transportation data model, UNETRANS (Unified Network for Transportation), developed by the University of California at Santa Barbara (UCSB) with financial support from ESRI. The “new and improved” UNETRANS is designed to provide a full structure that embraces all of a large organization’s data and access mechanisms. This enterprise data model also takes advantage of technological advances in the ArcGIS family since the original UNETRANS was developed several years ago.
However, developing an enterprise data model need not be the first step in creating an enterprise geodatabase. Your organization may first want to construct a workgroup prototype to gain experience with the geodatabase structure and how to use it. Effective geodatabase design and deployment