Why OpenITS

The problem

Intelligent Transportation Systems have accumulated fragmentation over decades. The same concept (a signal phase, a pavement temperature, a message-sign state) is represented differently by every vendor and re-integrated separately by every agency. The result is that ITS data is effectively invisible across organizational boundaries: agencies can’t build cross-jurisdiction analytics, vendors rebuild the same integration fifteen times, and researchers can’t generalize a finding from one deployment to the next.

Four failure modes

Fragmentation shows up in four recurring ways:

• Per-vendor data shapes. The same concept lives at different OIDs with subtly different semantics. Code that reads one controller doesn’t read another.
• Per-agency surface. Unified pictures are hand-rolled against one agency’s particular vendor mix. They aren’t portable, and the dashboards don’t generalize.
• Models tied to transport. Cross-agency standards bind the data model to a single protocol, so the model can’t outlive the pipe it shipped on.
• Schema drift. A new field breaks consumers silently. Without a registry, a graduation path, or proof of shared implementation, nobody can trust a schema over time.

The thesis

The bet behind OpenITS is simple to state: make ITS data as interoperable as web APIs. A consumer written against the model should read any conforming agency or vendor without modification: the code that reads one conforming agency should read any other, unchanged.

What changes

OpenITS attacks each failure mode directly: a vendor-neutral data model replaces per-vendor shapes; a testable conformance bar replaces per-agency surfaces; a deliberately transport-neutral model outlives any one protocol; and an immutable, content-addressed registry makes schema drift impossible to do silently. The next section describes how those pieces fit together.