A city parking system for Dhaka South City Corporation

End-to-end digitisation of parking operations, with real-time space utilisation and vehicle movement.

Client
Dhaka South City Corporation
Location
Motijheel, Dhaka
Project type
City parking system
Status
In production
Result
A live record of the district kerbside.
A wide arterial road in Dhaka in daylight, filled with queued buses, cars and taxis under a hazy skyline.
A public road in Dhaka, openly licensed and colour graded to the site palette. It is not the deployment site, not a client's equipment, and not a photograph of the system described below.

The client

Dhaka South City Corporation is the municipal authority for the southern half of Dhaka. Motijheel is one of the busiest commercial districts in the city. They are named on this page with their written permission.

The challenge

Kerbside parking in one of the busiest commercial districts in Dhaka ran on manual collection and no record of what was where.

The constraintPeak is eight in the morning, and it had to work with the access control and payment already installed rather than replace it.

Objectives

  • Produce a record of kerbside occupancy where none existed.
  • Digitise collection end to end, rather than digitising the receipt at the end of it.
  • Work with the access control and payment hardware already installed on site.
  • Hold up at the morning peak, which is when the district is least forgiving.

Built on Smart Parking, a platform we own and operate rather than resell.

What we built

Kerbside parking in a district like Motijheel is a cash business run on paper. Nobody can say how many spaces are occupied at eleven in the morning, which means nobody can say how many should have been paid for. The gap between those two numbers is invisible until something starts recording it.

That is the problem a parking system actually solves. Not convenience. Visibility. So the system digitises occupancy, vehicle movement, access and billing end to end, and produces a live record of the district kerbside.

The smart parking system, showing live bay occupancy against access and monitoring controls
Smart Parking, the platform this engagement runs on. Screenshots on this site come from our public demo tenant on generated data, never from a client's live system.

What it does, in production.

  1. Occupancy

    Space utilisation as a live figure rather than a monthly estimate.

  2. Vehicle movement

    Entry and exit recorded as events, so the record is built by the operation rather than after it.

  3. Access workflows

    Integrated with the barriers and controls already on site.

  4. Billing

    Collection digitised end to end, not a paper process with a screen at the end of it.

  5. Real time monitoring

    The operator sees the district as it is, not as it was at the last count.

  6. Operational visibility

    The record the authority never previously had, which is the point of the deployment.

The shape of the system.

The failure this system addresses is a missing link in a chain: three things happen at the kerb and the fourth, a record, never does. The architecture exists to close that chain at the moment the event happens rather than to reconstruct it later.

The integration map, the data model and the deployment topology are covered in technical review under NDA rather than on a public page. The shape of the system is described here; the detail is a conversation, not a download.

BeforeA bay is occupiedCash changes handsA paper slip, maybeNothing is recordedAfterA bay is occupiedThe parking is recordedThe payment is matchedAnyone can see what is freeNot convenience. Visibility.

How it was delivered.

A parking system that requires the barrier to be replaced first is not a parking system. Integration with the installed access control and payment hardware was a precondition of the design, not a phase of it.

Peak load is eight in the morning in a commercial district. Correctness at the busiest hour was the acceptance condition, because that is the hour a manual process is least able to cover for the software.

Engineering challenges

Someone else’s hardware

The equipment on site was chosen before we arrived and is not ours to change. Everything the software does at the kerb has to survive that, including the failure modes we did not pick.

A record that has to be right at 08:00

Off-peak correctness is easy. The system is judged at the hour when vehicles arrive faster than anybody can write them down, which is the hour the old process was worst.

What changed.

  • A live record of the district kerbside where there was none.
  • The system is in production and we are still the ones supporting it.

This engagement carries no metric, and the reason is worth stating plainly: nobody has asked Dhaka South City Corporation for one. Revenue recovered, spaces covered and collection rate are all figures they hold rather than figures we hold. If they share one, it appears here with its method and its date.

TechnologyReal time event capture at the kerb · Integration with installed access control and payment hardware · Operator dashboard, browser delivered · Occupancy and movement reporting

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build