Making a transport system visible

Central Facility is the operational interface for a cooperative intelligent transport station. It helps teams monitor roadside and central infrastructure, inspect the messages being produced, manage station configuration, and test how the system responds to an event.

I joined when the original JavaScript interface had reached the limits of the pilot it was built for. I led the frontend rebuild as a TypeScript application that could support more operational domains, wider jurisdictional use, and libraries that were still actively maintained.

The Events page was not a map added to a dashboard. It was the place operators used to understand what the transport system was saying now. An initial GraphQL query loaded current messages; an AppSync subscription added, updated, or removed them as the system changed.

I kept search, filters, visibility, selection, and the details panel on the same entity model. Selecting an event, intersection, road segment, simulated event, or quadtree tile changed both the map and the information beneath the search bar. Filters and map themes persisted between sessions so an operator could return to a familiar working view.

Operators also needed to rehearse behaviour without waiting for a real road event. I integrated simulated-event creation into the same map: choose a location, describe the event in a validated form, then manage it beside live messages.

The useful detail was what happened next. The backend normalised the simulated event and sent it through the ordinary C-ITS message workflow. The resulting message returned to the map through the same live update path, so the test exercised more than a visual mock.

A red count is useful only if the operator can find the failure behind it. I built health views that started with normal, degraded, and failed totals across selected organisations, then connected those summaries to station tables, a map view, and station-level diagnostics.

On the Events map, intersection markers also carried the health of their associated roadside stations. A degraded or failed station changed the intersection treatment; selecting it opened the associated stations and provided a path into detailed metrics and the affected communication flow.

Central Facility also changed the system it monitored. Its settings covered central-station behaviour, data sources, C-ITS use cases, and whole-of-system parameters. Some values affected message generation or every station in a deployment.

I built metadata-driven forms around that risk. The interface tracked original and pending values, validated changes before submission, kept unsaved work visible while navigating between parameter groups, and described who could change a value and what the change would affect.

The same approach supported roadside and vehicle station workflows: typed forms, partial updates, role-aware actions, and one consistent route from a list into creation, editing, and diagnostics.

I structured the application as lazy-loaded operational routes inside an authenticated shell. Health, settings, stations, and the Events workspace each received their own providers and domain state instead of sharing one undifferentiated store.

Central Facility became a production operational interface for health monitoring, live event inspection, station management, configuration, diagnostics, and testing. The TypeScript rebuild gave those domains explicit routes, stores, types, and reusable interface patterns.

I also wrote and maintained the operator manual, the detailed UI design, developer guidance, and Storybook examples, then backed the implementation with Vitest and Playwright coverage. Another engineer could follow both how the system worked and why the frontend was shaped that way.

The map work also changed how I thought about later platforms. Central Facility proved that geography could be the primary interaction surface for real transport operations. Map Core and Map Kit turned lessons from that product into reusable packages.