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 transportation geodatabases is to create relatively short segments, such as may be defined by address blocks. In order to assure atomicity in segment attributes, you may want to consider breaking such block centerline features wherever there is an obvious change in an attribute at a midblock location. For example, if you will store segment width as an attribute for such applications as determining lane miles, then you will need to break segments wherever width changes. If there is a transition section, then make it part of the narrower segment and start the wider segment where the new full width begins. Cul-de-sac width should not affect lane mile calculations, so do not create a special cul-de-sac feature class unless you need to include culde-sac diameter as a network parameter to establish the cost of U-turns. (See chapter 13.)
You may also want to consider going with separate centerlines when faced with a divided road with different primary characteristics on each side of the road. An alternative would be to store attributes by side of the road.
At most locations, the logical centerline will closely approximate the location of the facility. The most common exception, save for the issue of roadway splits discussed earlier, is at limited-access highway interchanges. Most state DOTs use a form of linear location referencing, such as route-milelog. They also commonly place the point of intersection between a ramp and the main highway at the physical gore, as this is the location