ТОП просматриваемых книг сайта:
Designing Geodatabases for Transportation. J. Allison Butler
Читать онлайн.Название Designing Geodatabases for Transportation
Год выпуска 0
isbn 9781589482913
Автор произведения J. Allison Butler
Жанр Базы данных
Издательство Ingram
• 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 attribute values along its length.
When dealing with a logical centerline, you can construct a one-to-one relationship between a facility and its representative geometry by breaking the geometry into segments. One segment has one centerline and one set of attribute values. Switch to carriageways for your geometry, and you now have one or two linear features for each facility segment, which is still manageable. Make the jump all the way to edgelines, and the number of representative edgeline features can be very large. Worse, you no longer really have a line that can be used to display common attribute values, like number of lanes and functional class. You could go with polygons, but they really look like wide centerlines and present problems at intersections.
Linear facilities are not the only things affected by the level of abstraction. Intersections and other junctions also present abstraction issues. An intersection is an atomic feature in the real world. The intersection of two divided roads is one thing; however, if you adopt a carriageway representation, then you will have four points where the physical centerlines cross. Also adopt the definition that an intersection exists wherever