Transportation and traffic
Counts, speeds and parking occupancy by corridor and zone.
- Corridor dashboards
- Parking occupancy by zone
- Alerts on detector faults
Government and Research / Smart City Data
A smart city data platform built on open standards
Traffic counters, parking sensors, air quality monitors and streetlight controllers each arrive with their own vendor portal, and none of them talk to each other. Agnotic Technologies builds smart city data platforms that bring those feeds into one store on open standards, give each department its own view and publish open data with privacy rules applied first.
Open standards
NGSI-LD and SensorThings
Open data
Published with DCAT metadata
Privacy
Applied before anything is stored
Trusted by global innovators
Industry Overview
What is a smart city data platform?
A smart city data platform is the shared system a city uses to collect sensor feeds such as traffic counts, parking, air quality, street lighting and waste, store them in one model on open standards, give departments dashboards and alerts, and publish safe data as open data. Agnotic Technologies builds these platforms for city agencies.
Who it is for
Which city teams use the platform?
One platform, with each department seeing its own assets and alerts.
Public works and lighting
Streetlight status, energy use and bin fill levels for crews.
- Outage alerts to work orders
- Energy use per circuit
- Collection route inputs
Environment and sustainability
Air quality and noise readings with calibration records.
- Readings by neighborhood
- Calibration history per sensor
- Public air quality data
Open data and IT
Data catalog, APIs, security and vendor onboarding.
- Dataset catalog with DCAT
- API keys and usage
- Device security status
Industry Challenges
Why do smart city sensor programs stall?
The failure points we see when a city tries to join its pilots into one platform.
Every pilot came with its own vendor portal, so data stays in that portal and ends with the contract.
Two vendors describe the same street differently, so their data cannot be joined on one map.
Camera and licence plate data is kept by default, with no retention rule anyone signed off.
Open datasets were published once and never refreshed, so the public stopped using them.
Field devices run old firmware with default passwords, and nobody owns patching them.
Each department buys sensors separately, so the city pays for overlapping networks.
Data sensitivity
Which city data is safe to publish?
The sensitivity table we fill with your privacy officer and data owners. Personal data is handled at ingest, before anything reaches the shared store.
| Data type | Personal data risk | Retention approach | Publish as open data? |
|---|---|---|---|
| Traffic counts from loops and radar | Low: counts with no identifiers | Keep aggregates long term | Yes, as counts by location and interval |
| Parking occupancy sensors | Low | Keep occupancy history | Yes, as occupancy by zone |
| Air quality and noise | Low | Keep readings and calibration records | Yes, with sensor and calibration metadata |
| Streetlight status and energy | Low | Keep for maintenance and energy reporting | Usually, at asset level |
| Licence plate reads | High: links vehicles to places and times | Shortest period your policy allows, with restricted access | No |
| Traffic camera video | High: people and vehicles can be identified | Short retention; derive counts at the edge where possible | No; publish derived counts only |
| Wi-Fi or Bluetooth presence | High: device identifiers can track movement | Hash or discard identifiers at collection | No; publish aggregated flows only |
Our Approach
How should a city approach the platform?
Three decisions we make with your IT, data and department leads.
Set the data model before buying more sensors
Procurement asks vendors to deliver NGSI-LD or SensorThings output, so new sensors join the platform without custom work.
Separate personal data at ingest
Identifiers are removed, hashed or kept in a restricted zone as each feed arrives, according to the sensitivity table.
Publish by default what is safe
Low-risk datasets go to the open data catalog on a schedule, with DCAT metadata, so publishing is not a manual project.
Capabilities
What do we build into a smart city data platform?
The smart cities services we build for city IT and departments.
Vendor feed adapters
Connectors that turn each vendor's API or files into the city's data model.
Context store
Current state of every sensor and asset in an NGSI-LD context broker.
Observations API
Sensor readings and metadata served through the SensorThings API.
Asset and location registry
One register of devices, poles, zones and streets that every feed refers to.
Department dashboards and alerts
Views and alerts per department, with faults sent to work orders.
Open data portal feed
Scheduled dataset publishing with DCAT metadata to your open data portal.
Privacy controls
Ingest rules from the sensitivity table, restricted zones and retention jobs.
Device security monitoring
Firmware, credentials and connection status for field devices.
How It Works
What does the reference architecture look like?
The layers we build, from the sensor on the pole to the public dataset. Each layer can be swapped without rebuilding the others.
Sensors and vendor clouds
Field devices report directly or through each vendor's cloud.
01
1
Ingestion adapters and broker
Adapters map each feed to the city model; a message broker buffers and routes them.
02
2
Privacy layer
Sensitivity rules strip, hash or restrict personal data before storage.
03
3
Context store
The NGSI-LD broker holds the current state of every asset and sensor.
04
4
History store
Time series storage keeps readings for analysis and the SensorThings API.
05
5
Department dashboards and alerts
Each department sees its assets, trends and alerts, with links to work orders.
06
6
Open data and APIs
Safe datasets publish to the catalog with DCAT metadata, and APIs serve developers.
07
7
Engineering Stack
Systems and standards behind a smart city platform
Open standards first, so the city owns its data model. We build in your cloud account or data center.
Standards
ETSI NGSI-LDOGC SensorThings APIW3C DCAT 3MQTT and HTTPS for device feeds
Data
Context brokerTime series storeAsset and location registryGIS integration
Applications
Department dashboardsAlert rulesOpen data publishing jobs
Security
Device identity and certificatesNetwork segmentation for field devicesSSO for staffAudit logging
Measured Impact
What should a city track on the platform?
Measures we build with your IT and department leads.
Feed health
Sensors reporting
Devices online, late or silent, by vendor and department.
Freshness
Open data updates
When each public dataset was last refreshed.
Faults
Alerts to work orders
Device and asset faults, and the time to a work order.
Security
Device posture
Devices on current firmware and without default credentials.
Use Cases
Where do cities start?
First releases we scope, each one on the open data model from day one.
01
One corridor
Traffic and parking data for one corridor on the shared model.
02
Air quality network
Readings, calibration records and a public dataset.
03
Streetlight program
Outage alerts and energy reporting from light controllers.
04
Open data refresh
Existing datasets republished on a schedule with DCAT metadata.
05
Vendor consolidation
Several pilot portals moved into one platform the city owns.
06
Smart cities for startups
A sensor startup's integration layer that outputs NGSI-LD or SensorThings for city buyers.
Integrations
Which city systems feed the platform?
The systems a city data platform reads from or writes to, agreed during scoping.
Transportation
Traffic detection and signal systems
Parking
Parking sensors and payment
Environment
Air quality and noise monitors
Public works
Streetlight control systems
Locations
GIS
Operations
Work order and asset management
Publishing
Open data portal
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
General Data Protection Regulation
Implement lawful consent flows, data minimization, and secure processing for global data privacy.
Service Organization Control 2
Verified controls for security, availability, and confidentiality of enterprise data systems.
Information Security Management
Adhering to the international gold standard for managing information security risks.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does a smart city platform engagement work?
A city platform grows from one department or corridor. The first release is defined and dated once we have seen your vendor feeds.
01
Scoping call
We review your current sensors, vendor contracts, open data portal and first use case.
02
Data model and sensitivity workshop
Departments and your privacy officer fill the data model and the sensitivity table with us.
03
Fixed-scope first release
Adapters, context store, one dashboard and one open dataset, with privacy rules applied.
04
Procurement language
We help your team write data format requirements for future sensor purchases.
05
Scale and support
More feeds and departments, device security monitoring and change control.
Facts and sources
Which standards shape a smart city data platform?
Short facts about the open standards and security guidance we build on, each linked to its primary source.
The OGC SensorThings API provides an open, geospatial-enabled way to interconnect IoT devices, data and applications over the web; its Sensing part is a standard way to manage and retrieve observations and metadata from different sensor systems.
Source: Open Geospatial Consortium, SensorThings APIETSI GS CIM 009 specifies the NGSI-LD API for context information management; version 1.9.1 was published in July 2025.
Source: ETSI GS CIM 009 V1.9.1DCAT Version 3, a W3C Recommendation of 22 August 2024, is an RDF vocabulary that lets a publisher describe datasets and data services in a catalog so metadata from many catalogs can be aggregated and searched together.
Source: W3C, Data Catalog Vocabulary (DCAT) Version 3NIST SP 800-213 helps organizations work out the device cybersecurity requirements they should expect from an IoT device and its manufacturer before they acquire it and connect it to their systems.
Source: NIST SP 800-213NISTIR 8259A defines an IoT device cybersecurity capability core baseline, the device capabilities generally needed to support common security controls, as a starting point for devices an organization will acquire.
Source: NISTIR 8259A
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related pages
Related government and IoT services
This page covers city-wide sensor data. These pages cover the services, buildings and networks around it.
Unified citizen services gateway
Resident-facing services, identity and payments.
Smart building IoT platform
Sensors and controls inside a single building.
Smart grid monitoring dashboard
Grid sensor data and alerts for utilities.
SCADA integration services
The boundary between operational technology and IT systems.
Government and research software
Public sector and research platforms we build.
More in Gov & Research
More Gov & Research Solutions
Explore other production-grade engineering platforms we deliver across gov & research.
Frequently Asked Questions
Usually not. We write an adapter for each existing vendor feed that maps it into the city's data model. New purchases can then be asked to deliver NGSI-LD or SensorThings output directly.
NGSI-LD is the ETSI API for context information, such as the current state of a parking space or a streetlight. Holding city data in an open standard means the city, not a vendor, owns the model and can change suppliers.
As high-risk data. Where possible, counts are derived at the edge and the images are not stored. Where raw data must be kept, it goes to a restricted zone with the retention your policy sets, and it is never published.
Yes. Datasets marked safe in the sensitivity table publish to your portal on a schedule, with DCAT metadata so catalogs and search tools can find them.
Devices get their own identities and certificates, field networks are segmented from city IT, default credentials are removed, and firmware status is monitored. We use NIST IoT guidance when writing device requirements for procurement.
The number of vendor feeds, how much data history to migrate, the departments and dashboards in scope, privacy handling for sensitive feeds and open data publishing. Each vendor adapter is a separate piece of work, so the estimate comes after we have listed your feeds.
The vendor feeds decide it: some vendors offer clean APIs, others only file exports. We set the date for the first corridor or department after reviewing each feed.
Industries