Updated 2026-10-09

The binding in one sentence

A vehicle finds its lane in the MAP, reads the signalGroup on the connectsTo entry for the maneuver it intends, finds the MovementState with that signalGroup in the SPaT for the same intersection, and obeys its eventState and timing. Nothing else links the two messages. If the IDs, revisions or signal group numbers disagree, the vehicle sees a signalized intersection with no usable state, and every application that depends on SPaT stays silent.

What must match

Worked example with the portal's templates

Load the MAP and SPaT templates in the creator (or open both in the decoder). Both are intersection region 0, id 1201, revision 3, Broad St & West St in Falls Church, VA.

The MAP has six lanes:

The SPaT has four movement states:

Follow one vehicle. It is eastbound on Broad Street, so it matches lane 1. It intends to go straight; lane 1's only connectsTo is to lane 2 with signal group 2. Signal group 2 in the SPaT is protected-Movement-Allowed with minEndTime 1450: green, ending no earlier than 145.0 s past the hour. A pedestrian waiting at the south-leg crosswalk is on lane 6, signal group 8, which is WALK (protected-Movement-Allowed) with an exact end at 130.0 s, consistent with the parallel eastbound green. Signal group 6, the crosswalk across Broad Street, is DON'T WALK while Broad Street has the green, which is the consistency a reviewer should check: the pedestrian movements must agree with the vehicle movements they conflict with.

Now change the MAP's revision to 4 without touching the SPaT, encode, and decode both: the portal's summary flags the mismatch, and a real OBU would discard the pair. Change signal group 4 in the SPaT to 3 and the northbound lane has no state at all.

Pitfalls

Permissive versus protected. A left turn on a green ball that must yield is permissive-Movement-Allowed; a left-turn arrow is protected-Movement-Allowed. A through movement under a green ball is protected (nothing conflicts). If the generator maps every green to protected, a vehicle may be told it has the right of way for a permissive left. In the MAP, a shared through-left lane has two connectsTo entries, and under a permissive left they usually carry the same signal group; under a protected-permissive left (flashing yellow arrow) the left connection carries the arrow's own group.

Pedestrian signal groups. Crosswalks are lanes that connect to themselves. Their signal group must be distinct from the vehicle groups and must be what the generator emits for the pedestrian head, not the parallel vehicle phase. Pedestrian clearance (the countdown) is protected-clearance; a flashing hand is not yellow for vehicles.

Overlaps. A right-turn overlap has its own signal group in both messages. Mapping a right-turn connectsTo to the through phase's group is wrong when an overlap exists, because the arrow stays green through the adjacent left phase while the through is red.

Signal group 0. Reserved; a connectsTo with signalGroup 0 means "unsignalized", which is correct for a free right turn but a defect anywhere else.

Missing signal group in the SPaT. Usually a generator table that was built from the phase list and forgot the overlaps and pedestrian heads. The portal's live view lists MAP signal groups with no SPaT state.

enabledLanes. A lane with isVehicleRevocableLane (reversible lane, part-time bus lane, part-time turn lane) is inactive unless its laneID appears in the SPaT's enabledLanes. Authoring a reversible lane without the generator ever filling enabledLanes leaves the lane permanently off; filling enabledLanes with IDs the MAP does not mark revocable does nothing.

Revision mismatch after an edit. Every MAP edit must bump revision and msgIssueRevision and be followed by a generator update. Agencies that store MAPs on the RSU but configure the generator separately get out of step after the first change.

Region. A MAP with region 1 and a SPaT without a region are different intersections.

Lane-level geometry errors masquerading as binding errors. If the MAP's lanes are offset or mirrored, the vehicle matches the wrong lane and reads the wrong signal group even though the binding is correct; check geometry first.

Testing the binding in the portal

1. Encode or capture both messages and open the live view with your RSU forwarding to the portal, or paste both into the decoder.
2. The map overlay draws each MAP lane and colors each ingress lane by the current state of the signal group on its connectsTo: green, yellow, red, dark, or gray with a warning when the group is missing from the SPaT. Crosswalks are colored by their pedestrian group.
3. Hover a lane to see laneID, connection, signal group, state and the countdown computed from the TimeMarks.
4. The binding panel lists: ID and revision match, MAP signal groups not in SPaT, SPaT signal groups not in MAP (informational), enabledLanes not in MAP, and timing inconsistencies (minEndTime in the past, min > max).
5. Watch through a full cycle. Every lane should change color in the order the controller's phase diagram predicts; a lane that never changes has a wrong group.

For an intersection you are authoring in the map builder, assign signal groups by the controller's phase numbers from its timing sheet, then ask the signal technician which overlaps and pedestrian heads exist and what numbers the generator emits for them. Write the table down; it is the single most useful document in a connected intersection project.

Related reading

• CTI 4501, Connected Intersections Implementation Guide (consistency rules, signal group conventions, verification procedures); SAE J2735_202409 MapData and SPAT modules.
• How signal timing works, MAP, SPaT, signal priority, certification and plugfests for the interoperability events where these bindings are tested.