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 is an ongoing process. The needs of the organization and the capabilities of the technology both evolve. You will need an enterprise architecture that describes the computing environment and its business rules. Everything else will be somewhat reactive because you cannot possibly anticipate all data uses. You must be agile.
Agile methods
Since modern geodatabase design should be based on data modeling, this book includes a review of that process in chapter 2. But it is important to note that data modeling fits within a larger information technology process. Years ago, data modeling and application development were separate processes. Now, it is generally recognized that the speed of database access determines, to a large degree, application performance. This change is partly the result of application intelligence being built into the database management system, and partly the product of larger datasets with more data types. As a result of the stronger role for databases in application performance, data modeling is now central to application development with both following a common design process.
The agile data modeling and application design approach has been described by many practitioners, such as Scott W. Ambler, a Canadian consultant who has written several books on the subject. It is the key to surviving the changing needs of an organization and the potential solutions offered by technology. Attempting to define all the requirements up front is much riskier than following an agile methodology that can accommodate change. Thus, Designing Geodatabases for Transportation presents an enterprise data model only to demonstrate how all the pieces may be put together, not because the enterprise data model is a necessary first step to implementation. Again, the solutions offered here are more like the choices in a cafeteria: you can pick the ones you want. This book also guides you on making your selections. One size does not fit all.
Figure 1.1 Geodatabase design process The agile geodatabase design process illustrated here starts with a draft design based on a set of user requirements. Design components are tested through prototypes to ensure that the overall architecture and its key parts work and then the design is revised to correct any observed problems. A pilot is tested for scalability to ensure the design’s performance meets requirements under production load. (The Geodatabase Tool available as a free download from ESRI can help here.) The design is revised and tested again before the system is put into production. Although the figure stops there, the reality is that new user requirements are likely to be imposed following production deployment and the cycle begins again.
The agile method uses an iterative, team-based approach. Members of the team are not given separate assignments; all team members work together on each assignment. The ideal team member will have broad knowledge of the organization and its operational needs, the general requirements of the agile method, and expertise in one or more areas required for design development and implementation. The hallmarks of the agile method are its use of “good enough” documentation, which includes data models; frequent deliveries of solution components to get user feedback; and structured performance testing at the planned scale of deployment (number of users, transaction types and volumes, etc.). The number of and execution time for database queries and related operations determine geodatabase performance and, thus, application performance. While there may be several ways to reach the same result, you will want to use the one that provides the greatest performance. No one likes to wait. The only way to know which approach provides suitable performance is to test it under real-world conditions. Performance testing must be part of the geodatabase design process.
Figure 1.2 Agile design process at the enterprise level This figure shows the agile design process with extra structure when applied to an entire enterprise. The box on the right includes four of the eight components shown in figure 1.1. The four boxes on the left side provide the enterprise context for the agile process. High-level requirements define the overall scope. The system architecture defines the deployment environment, such as which relational database management system (RDBMS) product will be used, who will have responsibility for system maintenance, where the hardware will be located, and other constraints. Proof-of-concept prototypes may be necessary to ensure that the system architecture will perform as expected under production loads.
When you seek to apply the agile method to an entire enterprise, you need to break the project into deliverable components that fit within an overall framework. The enterprise framework allows the organization to balance the needs of various internal and external communities competing for limited development resources and to test fundamental aspects of the overall system architecture vital to major parts of the final system.
It has not been assumed that the enterprise of interest is a transport agency. This book takes into account the fact that many transportation data users do not actually care that much about transportation per se. These users need transportation data as a reference plane for other information, such as situs addresses tied to relative position along a transportation facility (street address). Map making is generally placed in this category. Thus, this book will show how to build transportation-oriented geodatabases that can support the editing of data needed by a variety of applications. The focus will not be solely on the more extensive data models suitable for larger organizations. The book starts with simple problems and solutions, growing in complexity in response to application requirements until it reaches the most complex problems posed by large transport agencies and transit operators. Some chapters, such as those on navigable waterways and railroads, are actually directed to users outside these industries.
Designing
