Signposts

Available with Network Analyst license.

Signposts provide the type of directional information found on highway road signs, such as exit numbers, connecting roads, and major destinations that can be reached along the connecting roads. If you have signpost data, you can use it to enhance the route directions generated by ArcGIS Network Analyst extension. For example, the road sign in the image below informs northbound drivers that if they take exit 242, they will enter the eastbound side of Interstate 80, which connects to Brighton and Ainsworth.

A short route along the arrow in the image above was created, and the directions, with and without signposts, are compared below. The third step in each case highlights the difference:

A driver who uses the second set of directions can avoid making a wrong turn by matching more of the information on the directions to the sign that is encountered on the road.

This signpost information for driving directions is specified by using a Signposts feature class and Signposts_Streets table. The feature class describes the text on the road sign, and the table identifies the street segments that are traversed when following directions given by the road sign.

It is possible, but not recommended, to create signposts yourself using the format described in the following sections. In either case, once the data is prepared, both the feature class and table must be specified on the Network Dataset Properties dialog box for them to be valid.

Signposts feature class

The Signposts feature class is a line feature class. In the case of a geodatabase, it must reside in the same feature dataset as the network dataset. In the case of a shapefile network dataset, it must reside in the same workspace. A Signposts feature class can support a maximum of 10 branches and 10 destinations. The table below describes the fields on a Signposts feature class that support two branches and three destinations.

Signposts feature class schema

Field	Format	Description
ObjectID	OID	Signpost ID (OID field).
Shape	Geometry	Geometry of the signpost (line geometry).
ExitName	Text	Exit number, for example, exit 242.
Branch0	Text	Name of the first street or highway at the end of a ramp, for example, I-80.
Branch0Dir	Text	Official direction of Branch0, for example, North, South, East, or West.
Branch0Lng	Text	Language of Branch0, for example, en, de, fr.
Branch1	Text	Name of the second street or highway that shares the physical road used by Branch0. If I-80 and Highway 30 shared the segment of road at the end of the ramp, Hwy 30 would be entered here.
Branch1Dir	Text	Official direction of Branch1, for example, North, South, East, or West.
Branch1Lng	Text	Language of Branch1.
Toward0	Text	First destination beyond where the ramp ends, for example, Brighton.
Toward0Lng	Text	Language of Toward0, for example, en, de, fr.
Toward1	Text	Second destination beyond where the ramp ends, for example, Ainsworth.
Toward1Lng	Text	Language of Toward1.
Toward2	Text	Third destination beyond where the ramp ends, for example, another city or a point of interest.
Toward2Lng	Text	Language of Toward2.

Signposts_Streets table

The Signposts_Streets table should reside in the same geodatabase or shapefile workspace as the network dataset. The schema for the Signposts_Streets table is as follows:

Signposts_Streets table

Field	Format	Description
ObjectID	OID	ObjectID field.
SignpostID	Long	Foreign key to ObjectID field on signposts feature class.
Sequence	Long	Sequence identifier for the maneuver segment. For TrueSequence maneuvers, this can be 1-K, where K is the maximum number of edges in a maneuver. For maneuvers with only first and last edges, it is 1 for the first edge, and 0 for the last.
EdgeFCID	Long	Feature class ID corresponding to the streets feature class in the signpost maneuver sequence.
EdgeFID	Long	Feature ID corresponding to the street feature in the signpost maneuver sequence.
EdgeFrmPos	Double	Used to determine the street feature where the signpost maneuver sequence begins.*
EdgeToPos	Double	Used to determine the street feature where the signpost maneuver sequence ends.*

*Notes regarding the EdgeFrmPos and EdgeToPos values:

• For travel along the edge in the digitized direction of the line feature, the EdgeFrmPos value is less than the EdgeToPos value.
• For travel opposite the digitized direction of the line feature, the EdgeFrmPos value is greater than the EdgeToPos value.
• For line features not logically split midspan to create multiple edge elements, the EdgeFrmPos and EdgeToPos values are set to 0.0 and 1.0, respectively. Otherwise, these values are set to the fractional values where the logical splits occur for the edge element.

For best performance, it is strongly recommended that a separate attribute index is created for each of the following fields on the signpost streets table:

• SignpostID
• Sequence
• EdgeFCID
• EdgeFID

Create a separate attribute index for each of the listed fields.

Learn more about indexing an attribute

Signpost example

The following image and attribute tables illustrate how the green sign can be modeled:

Note that the language fields were removed from the Signpost attribute table in this image.

• The signpost feature (symbolized as the thick blue arrow) gives directions for a turn across two street features; therefore, two records represent the signpost in the signpost streets table.
• Since the ObjectID of the signpost feature is 15, the SignpostID for both records in the table is 15.
• The EdgeFCID refers to a system-generated feature class identifier that is automatically assigned to a feature class when it is created. The streets feature class in this example was assigned 7.
• The EdgeFID refers to the ObjectID of a unique street feature in the streets feature class.
• Since the signpost feature begins on street 8489, the Sequence value for that record is 1.
• Since the signpost feature ends on street 8493, the Sequence value is 2 (optionally, the last edge could be assigned a value of 0 instead).
• Since street 8489 was digitized from south to north—the same direction as the signpost—the EdgeFrmPos and EdgeToPosition values are 0 and 1, respectively. The same is true for street 8493. However, if the digitized direction of the street went against the signpost direction, the 0 and 1 values would be switched.