Why MAP and SPaT belong together

2026-10-12, by ITS Roads

A SPaT without a MAP is a list of timers nobody can place on the road, and a MAP without a SPaT is a drawing. The two messages are one data product and should be authored, validated and tested as one.

Connected intersections broadcast two messages that are often procured, authored and tested separately. That separation causes most of the field problems we see.

What each message carries

A MAP message (J2735 MapData, message ID 18) is the geometry: a reference point, each lane as a list of node offsets in centimeters, the maneuvers each lane allows, and connectsTo entries that tie an ingress lane to the egress lane it feeds. Each connection carries a signal group number. MAP is static. The agency or its integrator prepares it once, loads it on the RSU, and it repeats at 1 Hz.

A SPaT message (SPAT, message ID 19) is the timing: for each signal group, the current state (for example protected-Movement-Allowed or stop-And-Remain) and the time until it changes, expressed as tenths of a second past the hour. SPaT is live. The controller generates it ten times a second and the RSU forwards it immediately.

The join is the signal group

A vehicle matches its position to a lane in the MAP, follows that lane's connectsTo to a signal group, and then reads that signal group's state in the SPaT. The signal group number is the only thing that links the two messages. If the MAP says the northbound through lanes use signal group 2 and the controller's SPaT reports phase 2 as signal group 6, the vehicle will show the driver the wrong light, or more often nothing, and nobody notices until a test drive.

Everything else can be individually correct. The MAP can pass every geometry check and the SPaT can be perfectly formed, and the intersection is still broken because the numbers do not line up.

What to do about it

• Author the MAP and the signal group assignment from the same signal timing sheet, and keep the mapping (phase number, signal group, movement) as a table in the project file.
• Validate the pair, not the parts: for every connectsTo in the MAP, confirm there is a signal group with that number in a SPaT captured from the controller, and that its state sequence matches the movement.
• Test with live data. Capture both messages from the RSU, decode them side by side, and watch one full cycle.
• When the timing plan changes (a new protected left, a flashing-yellow arrow, a re-numbered phase), treat it as a MAP change too, and bump msgIssueRevision.

Trying it here

The map builder can generate a SPaT that matches the signal groups in the MAP you drew, so you can decode both in the decoder and see the join. The live feeds page draws MAP lanes colored by their SPaT state, which makes a mismatch visible at a glance. The wiki has the long versions: the MAP guide, the SPaT guide and how MAP links to SPaT.

As always, these tools are for research, training and pilot planning. Validate the real messages against the standard and through your vendor's conformance process before anything goes on the road.

Research and training tool. Not for safety-critical use. Read the disclaimer. Questions or requests: tell us what you want to see.