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 road lines cross, and you will find yourself with four intersections at the junction of two divided roads when you really only have one real-world intersection. We can fix this problem for pathfinding applications with internal turns at an intersection, but not for inventory and highway safety, where we need one intersection feature to illustrate entities like traffic signals and crashes. An approach that would satisfy these applications would be to treat an intersection as a multipoint feature.
To preserve atomicity, you need to organize the multiple pieces around the singular entities they represent. The easiest way is to relegate the carriageways and edgelines to geometry-only status. Use them to make maps look better at larger scales. Attach the original data to the logical centerline. Do not try to duplicate the data for each carriageway; treat them as “dumb” lines. You can still supply a number of attributes to control map symbology, as we will show later in this chapter.
If you really need to add intelligence to the carriageways for some particular application, you can use a facility identifier and a side-of-road or track identifier to move data to carriageways. But there are ways to create carriageways as offset copies of the logical centerline that will meet the needs of most larger-scale applications. (See chapter 8.)
As for the intersections, put them where the logical centerlines cross and ignore the intersections formed by dual carriageways. In addition to preserving the one-entity-to-one-geometry requirement, this practice will satisfy pathfinding applications that employ the logical centerlines. (See chapter 13 for an example.)
Figure 4.3 Centerline choices Although it easy to see logical centerlines on aerial photographs, they may not be so clearly discerned in the field, where data collection occurs. There is also the issue of the two carriageways having substantially different lengths, with resulting route measure issues. One solution is to store data by side of road, but this leaves the problem of unequal lengths unresolved. A more generally useful solution is to create separate directional centerlines. Adding carriageway geometry can give you the best appearance for either logical centerline choice.
There will be times when you really cannot use just one centerline, as in the example above. It is rather common to give a divided road one logical centerline and treat the fact that it is divided for all or a portion of its length as an attribute. You may even store data by the side of the road: left, right, and both. However, you will face situations where this approach does not work well, such as when each side of a road goes around an obstacle in the median. Another example is when a divided road with carriageways close together turns into a one-way pair with one or more intervening blocks full of buildings between them.
In both instances, you will want to create separate logical centerlines for each direction of travel. If necessary for the applications you intend to support, place an at-grade intersection at the junction of the single and double centerlines. Treat each centerline as its own facility. If you are using a linear referencing method (LRM) to locate positions along a centerline, reconcile the differences in length by resetting the origin of each centerline to zero. That treats each of the four centerlines as a separate facility within the database. You can readily combine all the resulting segments into a single traversal entity with one multipart centerline by selecting for route number. You will get different overall lengths depending on the direction of travel, which is appropriate for this example.
In addition to the guidance offered above, other practices can make your life easier and provide better data to the end user. You have already seen the need to make the relationship between entities and their representative geometry have a cardinality of one to one. The first task in meeting this requirement is to properly identify the entities.
Figure 4.4 Best practices—logical centerlines A logical centerline represents the approximate center of a linear transportation facility. This figure illustrates the basic rules for constructing roadway centerlines. The purpose of a logical centerline is to represent a facility at a relative small scale, reflect the linear datum’s rules, and support network connectivity. Appearance is a secondary consideration.
Figure 4.4 demonstrates a number of standard practices that will help you create logical centerlines for roads and railroads. Centerlines naturally go down the middle of the facility at the approximate midpoint. Do not offset the centerline when the width of the road changes asymmetrically. Extend the centerline all the way to the end of a cul-de-sac. Do not try to do anything fancy in a cul-de-sac, like shape it into a hook or circle, because that will disturb the correspondence between linear measures (addresses) and geographic location.
Put the crossing point of intersecting centerlines in the middle of the intersection, even if it means distorting the centerlines a little to accomplish that. Ignore channelized turning movements. You can give them a carriageway for large-scale mapping applications, but they are just internal details of a logical intersection. Offset intersections may be treated as one entity if that is the way traffic control works.
Use one centerline for each railroad track. You may generalize this to a single centerline for smaller scale mapping by including only the mainline track. Treat switch frogs and crossing diamonds as intersections.
Use multipoint geometry for railroad grade crossings, with one part at each intersection of a railroad track centerline and the road’s logical centerline. The railroad grade crossing will receive a single federal crossing identifier regardless of the number of tracks, so you want to preserve that atomicity. Think of a railroad grade crossing as a group of road-track intersections. The situation is similar to that presented by crossing carriageways, where the resulting one to four points of line intersection are to be treated as a single entity.
Figure 4.5 Geometric attributes Not all aspects of a facility’s geometry are contained in its geometric representation, particularly when a line of essentially zero width is used. Many descriptive properties are included as attributes of route event tables. This figure illustrates some the common practices for determining where the facility width attribute’s values may change. If you are using a predetermined segmentation design, and facility width is part of the segmentation decision, then these points of change represent segment endpoints.
Associated with the manner in which you construct geometric features to represent linear facilities is the manner in which you segment them. A common way to create
