By Charlie Frye, Esri Chief Cartographer
Indicating that a street is one-way and which way is valid to travel was a lot harder than it should have been prior to version 9.2. At 9.2, the new representations symbology makes this a much faster and easier task. To create this effect, you will need to have your street line data stored in a geodatabase which is a requirement for using representation symbology.
You will also need to have a field in your data that indicates whether a street is one-way. This also depends on the digitized direction of the street lines to align the arrows in the correct direction. If your streets are not digitized correctly, you can edit them by selecting each feature, set the Edit task to Modify Feature, then right click on the feature and choose Flip.
Start out by symbolizing your street layer using the line symbols (colors, styles, and widths) you would normally use. Don’t worry about adding arrow marker symbols to show direction for the lines. Make a copy of your street line layer and add a definition query to the copy so it only displays your one-way streets.
Create representations for your one-way streets layer (right-click on the layer in the Table of Contents and choose Convert Symbols to Representation). Open the Layer Properties and click on the Symbology tab and use these steps to set up the one-way symbols:
- Add a new marker layer to each street symbol (click where the number 1 is in the image below).
- Then change the marker placement option to “On line” by clicking where the number 2 is in the image.
- For Options (as shown below), make sure the Position is 0, Relative to is set to Line Middle, and the Angle to line option is checked.
- Click the Marker symbol and change it to an arrow. The default Esri style does not contain any arrowheads in the Representation Marker’s folder, so I created some (though explaining how to make markers is another topic and I will write about that later) and put them in a style called RepArrows.style that you can download.
- When you’re selecting the representation marker you can change its color by clicking the Properties button and then in the Marker Editor window, click on the marker, which will select it, causing its properties to show on the right, where you can change the color. Here is what the interface for my arrow looked like:
- Finally, remove the line symbol layer from your representations (the lines will be drawn with the original streets layer). To do that click on the Line tab (above that’s the squiggly line, whereas the point layer has the push-pin) and then the Remove Layer button in the row of buttons at the bottom.
Since this is representation symbology, it is stored in your database, and can be reused on any other maps that require the same solution.
Interesting… How do you recommend showing the correct arrow direction based on TF/FT field values that depend on digitized direction?
If the FNODE# field’s value is Less than the TNODE# field’s value then choose an arrow that points the the right. If the TNODE# field’s value is Greater than the FNODE# field’s value then choose an arrow that points the the left. (or if I got that backwards, switch the right and the left.)
Before you create representations, your would need to make a 2nd copy of your layer and add to the definition query for OneWay = true. In the first copy add: AND “FNODE#” > “TNODE#” and in the second add: AND “TNODE#” > “FNODE#”.
You’ll then create two sets of representations, one for each arrow direction. Y
If you only wanted one set of representations, you could add a new field that contains a 1 if the FNODE# > TNODE# and a 0 if not. Then use unique values (likely for many fields, if you are using different symbols for different types of roads) to incorporate this attribute into your symbology and thus your representations.
It appears that “TNODE#” is always > “FNODE#”, at least for a personal geodatabase source. Is there some way to query Measure directly in this fashion?
Interesting, I assumed you were working with coverages. That aside, I realized another issue with using the topology to deal with assigning one-way streets, which I think makes it untenable to do. If the streets also have address ranges so they support geocoding, then the digitized direction should follow the direction of the addresses, which will make the logic of from and to be less than to greater than, which is intuitive.
However, if the digitized direction is flipped because the street runs the other way, then the address range attributes would also need to be flipped. So that may be a different option for your query.
As for storing data in a personal geodatabase and querying for digitized direction, that won’t work as we don’t expose the node-id table (I’m just using the analogy of how it works in the coverage model, and not implying it works the same way in a geodatabase). So you’ll need an dedicated attribute to set up your symbology if digitized direction always follows address ranges.
Turns out the required logic is already built into our OneWay values. I created the second layer as suggested so that one provides ‘TF’ features while the other provides ‘FT’ features. Then, all we had to do was flip the arrow in one of these layers.
I’m not sure if we’ll want to modify our database schema to accommodate representations, but the end result displays nicely. Thanks for the post.
That’s a good way to solve the problem as well.