performance of a geodatabase. Performance is generally inversely proportional to the number of feature classes being used. ESRI provides a free Geodatabase Toolset that you can use when testing the geodatabase design prior to deployment. The functions available in the Toolset include:
• Editing information
• DBMS statistics
• User information
• Versioning lineage information in a state tree diagram
• Spatial index information
• Displaying versions in the geodatabase in a hierarchical tree view structure
• Relative data fetch timer
• Refresh data timer (per layer)
• Ability to start and stop DBMS tracking
• Scripting functionality
The Toolset timers will display the time required for database operations, like fetch, draw, and label, when working with feature classes. Since transportation databases involve many more tables than most geodatabase designs, you may need to use tools that came with your RDBMS to monitor geodatabase performance more fully. Of course, the ultimate measure of effectiveness is how long it takes to do useful work under production conditions. To answer this question, you will need to do performance testing with prototypes going against a populated geodatabase that is similar in size and complexity as the production environment.
Notes
1 Please note that these subtypes and their default values are included here solely to illustrate how subtypes work, not to explain how route designations are made.
Best practices in transportation geodatabase design
• Accommodating multiple street names
• Designing a pavement management system
A transportation geodatabase is an abstract representation of the real world. Depending on the application, we may choose one of several possible abstractions. Whatever form is selected, the abstraction does not represent all the aspects of the real-world entities.
Figure 4.1 Abstraction Most geodatabases are a collection of feature classes with representational objects consisting of points, lines, and polygons. The abstraction process to produce a geodatabase often “loses something in the translation.” While retaining the full richness present in the real world is not possible, that is not the objective of abstraction. The true purpose is to focus on real-world aspects most critical to a particular problem. Different critical phenomena, abstractions, and attributes are needed for each problem to be solved.
The key to successfully creating a usable abstraction is to represent the core aspects of the entities. Most forms of abstraction in a geodatabase revolve around the many ways you could construct geometry showing the shape and location of real-world entities. For most transportation geodatabases, the linear aspect of roads, railroads, and waterways is dominant. However, a transport agency must also consider the property—the right-of-way—on which those facilities exist. Planning and constructing changes and routine maintenance all require information about facilities. A transport agency, therefore, will likely have multiple abstractions stored in separate databases.
This chapter describes the common forms of linear facility geometry and suggests best practices to help you decide which form is best for your application. A later chapter will show several ways you can manage multiple abstractions in a single geodatabase.
Centerlines
By far, the centerline is the most common abstraction for linear facilities. There are two centerline subtypes: logical centerlines and carriageways (physical centerlines). A logical centerline represents the approximate midpoint of the facility across its width. A logical centerline does not care whether a road is divided or a rail line contains multiple tracks. The intent, after all, is to show the general location and shape of the facility at a relatively small scale. GIS is, by definition, concerned about geographic scales that provide relatively large spatial extents.
Figure 4.2 Road geometry A challenge with transportation-system abstraction in a geodatabase is settling on one graphical representation among so many choices. When the scale is very large, as with a CAD system for facility design, abstraction is relatively close to the real world, with lines representing the face and back of curbs, sidewalk and pavement edges, median islands, and other roadway structure details. At slightly smaller scales, many of these features disappear and carriageway centerlines represent the path followed by each linear piece of pavement. The highest level of abstraction provides a single logical centerline for each linear facility. Each of these geometric representations has a useful application, but no single choice meets all users’ needs.
Sometimes, though, you need to illustrate data at larger scales, where precise position and shape are more important. Here, you can use carriageways, which are physical centerlines. A divided road or a double-track mainline will be shown using two carriageways, one for each physical path that a vehicle could travel.
At really large scales, such as for engineering design and right-of-way management, even carriageways do not provide a sufficiently “real” abstraction. At such scales we may employ facility edgelines and start to treat the linear facility as an area with both length and width.
One consistent issue is atomicity, which refers to the indivisible nature of elemental entities. Geodatabase design is usually based on a one-to-one relationship between the entity in the real world and its representative geometry. Entity attributes are used to symbolize the geometry in a way that expresses some characteristic of the entity. The geometry has to be scalar. Atomicity is always a problem for linear transport facilities. A road, rail line, or waterway is typically very long and will have many changes in
