Integrating RD Analytics with Smart City IoT

Smart city programmes collect data from signals, loops, weather stations, parking sensors, and CCTV. The missing piece is often traffic analytics IoT integration: turning camera pixels into structured events that other systems can consume. Without that bridge, video stays in a surveillance silo while dashboards show yesterday’s counts.

This article explains how RD Analytics acts as a traffic sensor layer for smart city traffic AI platforms—especially alongside Road Data Systems’ broader stack such as RD Fusion—using exports and the Data API.

What “integration” means in practice

City architects usually need three outcomes:

1. Authoritative traffic measures — volumes, classes, speeds, occupancy—not only video walls.
2. Machine-readable delivery — APIs or files into BI, OT systems, and data lakes.
3. Governance — zone-scoped access, on-prem processing, clear ownership of data.

Municipal buyers and other video-analytics vendors stress the same procurement filters: work with existing cameras, produce actionable structured data, and clarify who owns the data. RD Analytics is aligned with that checklist: camera-agnostic file/stream inputs, browser ops, and API read access for ETL.

Reference pattern

Cameras / drone files
        │
        ▼
 RD Analytics (detect → track → classify → count)
        │
        ├── Interactive reports (engineers, consultants)
        ├── CSV / Excel / track exports (project delivery)
        └── Data API (ETL → IoT platform / BI / RD Fusion)

Recognition can stay on municipal GPU servers. Only metrics and tracks need to move to the city platform—not continuous raw video—reducing bandwidth and privacy exposure.

What the Data API exposes

RD Analytics provides read-oriented data endpoints (typical base https://<host>:9006/api) for integrators:

Authentication uses API keys (machine-to-machine) or JWT. Keys are zone-scoped so a parking bureau cannot pull an unrelated corridor’s tracks.

Example integrator flow:

1. Admin creates an API key bound to the IoT zone.
2. ETL lists assets, discovers new completed scans.
3. Job pulls metrics for dashboards every 5–15 minutes (or batch nightly for surveys).
4. Track exports enrich safety or model calibration warehouses weekly.

See product docs for pagination, cursors, and export job statuses when wiring production ETL.

Pairing with RD Fusion and other IoT platforms

RD Fusion is Road Data Systems’ smart city IoT platform for combining traffic systems, sensors, surveillance, and third-party services. RD Analytics fits as the vision analytics producer:

• Fusion (or any city ESB) schedules pulls or receives pushes from middleware
• Operators see traffic KPIs beside asset and incident layers
• External partners get controlled shares without VPN access to the GPU hosts

The same pattern works with generic stacks: Azure IoT, AWS, on-prem Kafka, or a BI tool (Power BI, Grafana) via scheduled API extract.

Architecture options from the RD Analytics product line—local worker servers, central manager, optional cloud-hosted manager—exist specifically so cities can scale without hauling all video to one SOC.

Design tips for durable integrations

Example: corridor operations dashboard

A transport operations centre wants a corridor tile: volume, average section speed, and approach occupancy.

1. Configure scans with counting lines, speed segments, and density zones.
2. Process live or frequent batches (per licence and deployment).
3. ETL reads speed.avg, density metrics, and quantity aggregates via API.
4. Fusion/dashboard shows sparklines; clicking through opens RD Analytics for evidence (scene overview, events).

Engineers keep the rich UI; operators keep a simple IoT view. That split is what makes smart city traffic AI usable.

Example: planning data lake

A modelling team needs classified turning counts and O–D cells for annual model updates—not a real-time tile.

1. Survey scans complete overnight; status becomes COMPLETED.
2. ETL watches assets for new scans since the last watermark.
3. Async track export lands in the data lake as NDJSON/CSV.
4. A dbt/SQL job pivots line_first × line_last by class and hour into the model input schema.
5. QA notebooks sample event lists against a stored reference clip.

Same API, different SLA: nightly batch instead of minute-level metrics. Do not force planning extracts through an operations message bus if a file drop is enough.

Anti-patterns to avoid

• Streaming raw video to the cloud “for AI” when an edge worker could emit tracks locally
• One shared API key for every contractor (no zone scope, no revocation story)
• Renaming class groups weekly and breaking historical dashboards
• Building IoT tiles before a human has validated one junction report
• Assuming plates must flow to the city bus (they usually should not)

Security and privacy posture

• Process on infrastructure you control (LAN or private cloud).
• Scope API keys to zones.
• Export only fields you need (plates are opt-in on track queries).
• Align with local CCTV codes of practice; video analytics does not require publishing imagery to be useful.

Getting started

1. Stand up RD Analytics on a GPU host (installation guide).
2. Complete one junction report manually.
3. Issue an API key; pull /data/assets and one scan’s metrics.
4. Wire a single Grafana/Power BI panel before boiling the ocean.
5. Invite the IoT platform owner once the contract of labels and refresh rates is clear.

Talk to Road Data Systems about Analytics + Fusion architectures, or explore RD Analytics and the architecture overview for manager–worker scale-out.