Smart city applications are systems that let a municipality manage water, energy, transport, parking and waste using data from sensors in the field. Their value comes from reducing a measurable loss, not from a map on a screen: leaking water, lamps burning in daylight, lorries driving to bins that turn out to be empty. Start with one application that measures the costliest loss.
What does "smart city" actually mean for a council?
Councils usually meet the smart city idea from one of two directions. The first is a grand vision document: a city dashboard, a control room, one screen that shows everything. The second is an everyday problem: a pump that stops at midnight, a street lamp that has been out for weeks, bins overflowing every summer. Projects that deliver lasting results almost always start from the second.
Technically, every smart city application has the same four layers. There is a device that measures something in the field (a sensor, meter, camera or controller), a connection that carries the data (cellular, NB-IoT, LoRaWAN or fibre), a platform that collects the data and raises alarms, and the people who act on them. The weakest link is usually the device or its maintenance; our article on the remote monitoring IoT platform explains each layer in detail.
This article looks at smart city applications alongside a council's budget and maintenance capacity. For the organisational side, meaning applications, records and field crews, see our guide to digital transformation in municipalities.
The cost of not measuring: cities grow, losses stay hidden
The load on urban services keeps rising. According to the UN's World Urbanization Prospects 2025, 45% of the world's population lives in cities, and two-thirds of population growth to 2050 is expected to happen in cities. Serving more people with the same network, the same roads and the same staff makes knowing where the losses are essential.
In Türkiye, the clearest example is the water network:
According to Türkiye's Ministry of Agriculture and Forestry, the average water loss rate in drinking water networks fell from 39% in 2015 to 31.6% in 2024, and metropolitan and provincial municipalities must bring it down to at most 25% by 2028. (Ministry of Agriculture and Forestry, Urban Water Efficiency)
The same page lists wider use of remote monitoring and control systems, and minimum night flow analysis, among the recommended measures. Energy tells a similar story: the IEA's Energy Efficiency 2025 report says buildings account for around 30% of global energy demand. The IEA's 2017 Digitalization and Energy study estimated that digital tools using real-time data could cut building energy use by 10%, a potential that applies directly to council offices and leisure centres; street lighting can be tracked separately through its own panels. The network operator's perspective is covered in digital transformation in energy utilities.
Smart city applications: six areas and what they measure
The table below compares the applications councils most often deploy, by field device, connectivity and the indicator worth tracking. Each row can be a pilot on its own.
| Application | Field device | Typical connectivity | Indicator to track |
|---|---|---|---|
| Water network and pump stations | Flow/pressure sensor, pump controller, smart meter | Cellular, NB-IoT | Night flow, downtime, loss rate |
| Street and facility lighting | Panel meter, lighting controller | Cellular, LoRaWAN | kWh, number of failed lamps |
| Parking and vehicle entry | Number plate camera, barrier, occupancy sensor | Fibre, cellular | Occupancy, average search time |
| Waste collection | Bin fill-level sensor, vehicle GPS | NB-IoT, LoRaWAN | Share of wasted trips, overflow complaints |
| Council buildings | Energy analyser, building automation | Local network | Consumption per square metre |
| Public information | Digital displays, kiosks | Fibre, cellular | Usage and downtime |
On the water side, monitoring pump stations is one of the quickest ways to show results; our article on remote pump station monitoring explains which signals to watch. For meters, see our guide to automatic meter reading.
For parking and vehicle entry, number plate recognition, barriers and payment come together in one flow; details are in our articles on parking management systems and licence plate recognition.
For energy and HVAC in council buildings, our smart building and BMS guide is a sensible starting point. Software steps such as flagging full containers or road damage in camera footage are covered in AI in local government.
How to choose the connectivity
The number of connected devices is rising fast: IoT Analytics' State of IoT 2025 expects the number of connected IoT devices worldwide to reach 21.1 billion by the end of 2025 and 39 billion by 2030. For a council, though, the real question is which technology it can sustain in its own terrain with its own maintenance team.
Battery-powered sensors that send small amounts of data a few times a day, such as bin sensors and meters, suit NB-IoT or LoRaWAN. Mains-powered devices that also need to receive commands, such as pumps and lighting panels, are simpler on cellular. Data-heavy devices like cameras need fibre or a local network. The full comparison is in our article on LoRa vs NB-IoT vs cellular. How the same choice plays out in rural areas with weak coverage is covered in farm digital transformation.
Resistance to dust, water and impact is part of the choice too. An outdoor enclosure with the wrong rating starts failing in its first winter; our explainer on IP ratings makes that decision easier.
Plan for maintenance from day one. Replacing batteries in thousands of sensors, swapping failed devices on site and managing SIM cards stay in the budget far longer than the purchase price. A dashboard that shows each device's battery level and last check-in prevents blind spots from building up in the field.
Cameras, number plates and data protection
Some smart city data is personal data. A number plate read by a camera, a car park entry time or a household's hourly water consumption falls under Türkiye's Personal Data Protection Law No. 6698 (KVKK), broadly similar to the GDPR, as soon as it can be linked to a person. The purpose, retention period and who may access the data should be written down before the project starts.
Three rules work well in practice: collect only what the purpose needs (you don't have to store plates to measure occupancy), delete or anonymise records automatically when their retention period ends, and log who viewed which record and when. We cover camera-specific obligations in our article on CCTV recording and KVKK.
There is also the question of ownership: who will own the data the devices produce, and the platform's source code? If the contract does not say so explicitly, a council may struggle to reach its own data years later when it wants to change supplier. Data export formats and access rights belong among the mandatory clauses of the specification.
From pilot to city: a 6-step plan
- Pick one loss. Choose a problem you can express in money, such as water loss, lighting energy or wasted collection trips, and measure its current value.
- Limit the pilot area. Choose a manageable area: one district, one pressure zone or fifteen pump stations.
- Choose devices and connectivity to suit the site. Check power, coverage and maintenance access on the ground; don't rely on a coverage map.
- Connect data to the map and to work orders. An alarm shouldn't stay on a screen; it should reach the right crew as a located work order, with the closure written back to the GIS.
- Design security in from the start. Remove default passwords, restrict remote access and plan firmware updates; our article on OT security for SCADA provides a checklist.
- Measure the result, then scale. If losses fell in the pilot area, roll the same architecture out to new areas; if they didn't, find out why before scaling.
This sequence is easier to manage, in both budget and risk, than one large project covering the whole city. For the wider framework, see our digital transformation roadmap and the digital transformation topic page.
How we deliver smart city projects at Digital Bridge
We provide software and hardware from the same team: electronics and PCB design, mechanical enclosures, embedded software and web and mobile dashboards are all developed in-house. When off-the-shelf devices don't fit the site, for example because the power source or connectivity is different, our device manufacturing and IoT team can design devices for the job. Technical feasibility assessment for hardware is free of charge.
In discovery we map the loss the council wants to measure, the devices already in place and the maintenance team's capacity. In the pilot we install devices and connectivity in a limited area and show each site on a map in the remote monitoring dashboard. Alarm rules built on thresholds and combined conditions send notifications to the right person through the mobile app, and because the platform is offered as a monthly subscription, the council does not need to set up its own servers.
Where meter reading is needed, automatic meter reading (OSOS) fits into the same architecture, as does licence plate recognition for vehicle entry.
In the integration phase the data is connected to the GIS, work order systems and management dashboards. We can also help prepare vendor-neutral technical specifications ahead of a tender; see our public sector and municipalities page for more. Scope, phases and cost are always confirmed in a written proposal. Where council facilities such as offices, leisure centres or campuses also need staff and visitor entry control, SmartPass, which manages permanent cards and single-use QR codes under the same access rules, can be included in the same project.
Next step
Pick one loss you can put a figure on and write down its current value: monthly water loss, the lighting bill or the number of wasted trips. Then choose a sensible pilot area. Contact us with those two facts and we'll plan the site survey and pilot scope with you.