By Charlie Frye, Esri Chief Cartographer
We got a good question on Ask a Cartographer this morning. The gist of the question was how to go about symbolizing street centerlines so they could be drawn using line symbol widths that reflected, at scale, the actual width of the road (as shown in the image to the left). This is a good cartographic solution because varying the line width adds hierarchy to the roads -otherwise it would be hard for you map reader to know which are wider or more heavily used.
Over the past few years, I think I’ve investigated most of the possible solutions to this problem, from simply symbolizing already available street centerlines to more complicated and time consuming solutions that involve the creation of polygons from line features (such as curbs) simply to symbolize the streets. Basically, street centerlines are great until you zoom in far enough that you either see the imperfections in geometry or it’s obvious that the streets should be shown with much wider line symbols. The trick is to find that happy medium between the abstracted/cartographic look of hierarchically symbolized street centerlines and the engineered look that comes with exactingly digitized curb lines.
For instance, is something like the look of a map from Google what you want? Or, would you rather have something that shows the roads based on their real life width? I started out on this slippery slope pretty much the same as the person who asked the question. The main problem is that in most cases for GIS data that represent street centerlines, features are not coded by street width, i.e., there’s no attribute with the width, and the road class field doesn’t begin to account for the real life variety in road widths. So here’s how you can traverse the slippery slope, starting with the easiest solution:
1. I was making trails maps and I really wanted to make it easy for people walking on the roads between trails in Redlands to be able to locate trailheads relative to the characteristics of the roads. But, I did not want to digitize curbs–too much work! I wasn’t happy with the road class field as the basis for line width. Too many relevant details weren’t handled. So I spent some time refining the road classifications–adding additional categories, like trails, fire roads, and alleys, that I could use to try and assign various line widths to.
2. That was better, but I really wanted cul-de-sacs to look like cul-de-sacs. To try and solve this problem, I added another class to my line classification for roads that ended in cul-de-sacs. As, I showed in an earlier blog entry on symbolizing roads with cased line symbols. I used a representation rule to add the cul-de-sac point symbol to the end of the line road symbol. That wasn’t bad until I zoomed in a bit more and looked at my solution relative to some 1m pixel imagery and learned that many cul-de-sacs aren’t symmetrical and for that matter many roads aren’t either.
TIP: As I as enriching my road class field, I also realized the quality of my street centerlines, which was fine for 1:24,000 mapping, was a bit coarse for 1:4,000. So, I spent a good bit of time using the Reshape Feature edit task to refine the geometry of my street center lines, in particular to introduce true curves with the Endpoint Arc tool. I did this with my imagery in the background to help define the curves and verify my results.
3. What finally did the trick for me was to buffer my centerlines and then only when something exceptional, like where a cul-de-sac or parking area was located, did I do any manual editing. Here are some tips for doing that refined editing:
- Turn off the map’s reference scale. Too often I needed to be zoomed way in, like 1:800, and if you keep the reference scale on, the line widths become too wide.
- When you do have to zoom way in, always zoom to the same scale–that way you’ll get used to the proportions of elements you’re editing – that is, you begin to get a sense of the scale, which won’t happen if it keeps changing.
- I used the Endpoint Arc tool to create my cul-de-sacs–several areas of Redlands have a lot of variety in the shape, size, and symmetry of cul-de-sacs so this let me deal with those variations. It also worked when things were regularly shaped.
- For ‘standard’, symmetrical cul-de-sacs, I found that I once I made one feature, I could use the Cut Polygon edit task to sever the cul-de-sac off the end of the street, Copy it, and then use the Merge command on the Editor menu to re-attach the severed cul-de-sac. Then whenever I needed a standard cul-de-sac, I could just Paste, Move, Rotate (if needed), and Merge to attach a cul-de-sac to another street’s end.
- I found myself wishing, more than once, that I could use the Lasso Direct Select and then the Move Parallel tools from the Representation toolbar to select a few vertexes and move them. To get around that, I found I could select the street centerline and use the Buffer command on the editor menu to create a polygon. Then I used the Cut Polygon task to remove the unneeded parts, and then move the part I needed into place, and use the Merge command on the Editor menu to merge that polygon with my street polygon. It’s almost as fast as editing representations, and certainly faster than manually editing each vertex.
So hopefully this helps you, no matter where you choose to place yourself on this slippery slope of cartographic street editing.