Designing Geodatabases for Transportation. J. Allison ButlerЧитать онлайн книгу.
Geodatabase field types
• Subtypes
• Origin and destination tables
This book shows how to build geodatabases that can be easily edited. In chapter 2, the geodatabase was shown to be an object-relational database that the user customized to provide the data and behavior desired. The object-oriented foundation of a geodatabase offers advantages, such as extra functionality, over a purely relational database. Many of the functions you would normally have to program, like domain checking and rule enforcement, are already part of the geodatabase.
Other geodatabase benefits that are especially useful for transportation datasets are:
• The dataset is continuous. In the past, traditional spatial data structures needed to subdivide their spatial data into tiles of relatively uniform density. Transportation datasets can be quite large. The geodatabase is continuous regardless of database size so a tiling scheme is unnecessary to efficiently manage data.
• The data is uniformly managed. Data with and without geometry can be managed in a single repository, assuring that both kinds of data are integrated and internally consistent. This book will show you how to asynchronously edit feature and object classes to preserve referential integrity.
• Many users can edit the data simultaneously. In larger transport agencies, several workgroups likely would be responsible for editing various portions of the enterprise dataset. The geodatabase can handle simultaneous editing cycles located at multiple sites.
• Data entry quality assurance is built in. One of the critical concerns for maintaining large datasets is assuring that only good data is put in. The geodatabase provides mechanisms to control what is entered into the dataset.
• Users work with more intuitive data objects. A properly designed geodatabase presents the user with multifaceted objects that combine spatial and nonspatial data into a single composite. Spatial features are no longer “dumb” points and lines but become roads, train stations, and bus stops. Nor is each type of object isolated from the others. By using an integrated geodatabase, you can maintain the relationships between objects. You can even use them during editing to specify what happens to other features when you move or modify a different feature.
Designing a geodatabase is a process of deciding which capabilities to use. You are not starting from a blank sheet of paper. The basic framework for an efficient enterprise design is already in place inside the geodatabase.
The geodatabase
The geodatabase is a collection of ArcObjects, but that simple definition does not really tell you what it does. ArcObjects interact with each other. If you establish a topological relationship between two lines, a change in one line can produce changes in the other line. Or you could create a connectivity rule that says a surface street may not connect directly to a limited-access highway, only to an exit ramp. You can control the direction of one-way streets or ensure that water always flows downhill. You can specify a particular map appearance for a given situation, such as label placement that does not overlap another feature. You can click on a feature and have a form appear. All of these functions are possible because the components of a geodatabase interact with each other and the user.
Figure 3.1 ArcGIS geodatabase feature dataset An ArcGIS geodatabase feature dataset can contain different class types. The more common types are discussed here.
A geodatabase consists of feature datasets, domains, validation rules, raster datasets, TIN datasets, survey datasets, metadata documents, and locators. A feature dataset can have a spatial reference that is shared by all the feature classes in the dataset. Transportation networks, geometric networks, and planar topology rules can be in a feature dataset.
Transportation data users are most concerned with four geodatabase class types: tables, features, relationships, and transport networks. ArcGIS supplies a uniform appearance for all these class types regardless of the database management system environment you implement.
A table is a class for which you can specify attributes and behaviors to represent an entity in the real world. It looks just like a relational table. ArcGIS even creates a primary key field, called OBJECTID, for you. Of course, you can create another field that can also uniquely identify each row in the table in order to support association relationships.
Although the OBJECTID field supplied by ArcGIS for all tables and feature classes is the primary key used by the software, it is not really a good foreign key for you to rely upon. The problem with OBJECTID is that it has values that can change as a result of certain database operations. For example, if you merge members of two tables into one, the OBJECTID values can change. Any foreign key relationships that you had constructed using OBJECTID no longer would work because those OBJECTID values are now gone or (worse) apply to other rows.
You create a candidate primary key in each of the classes that you will want to link to another class through a foreign key, whether it is implicit or instantiated in a relationship class. Some ways to do that are presented later.
Most ArcGIS documentation describes a feature class as a table class with a shape column. But a feature class also has all the added software required to work with geometry.
A transportation network uses feature classes as the source for information to construct a logical topology of the system and its behaviors. For example, you can define sign features to guide users who perform pathfinding analyses, or turn tables to express the temporal restrictions of movement by particular vehicle types at junctions.
Relationship classes manage associations between classes, although you can also rely upon on-the-fly relates and joins to tie classes together using foreign keys. Relationship classes are an important part of many best practices for transportation database design.
The geodatabase framework
The balance of this chapter is one big rocket science sidebar that will take you “under the hood” to present the internal structure of the ArcGIS geodatabase. If you don’t want to get your hands dirty, you can skip to the next chapter. However, if your job is to guide the data modeling process, create or implement the physical data model, or manage the geodatabase once it is created, then you are the mechanic others will rely upon and you will benefit from knowing how the geodatabase works. Of course, transportation types tend to like to take things apart to see how they work, so feel free to read this chapter for sheer pleasure, regardless of your role in a database development project.