Industries · 7 min read
Parking lot occupancy detection from the camera already over the car park
A region per bay, occupied or empty as the call, a free-bay count for the sign and the manager, and snow, glare and a nudged lamp post as what goes wrong.
Summary
This post describes parking occupancy from the security camera a store already has on its lamp post: vehicles boxed, a region drawn per bay, and a free-bay count that goes to the sign at the entrance and to the manager. It concludes that snow and night glare are the weeks the model doubts and that a nudged mount is the failure to expect, because it moves every bay at once. It is for store operations and property teams.
Finn Ellingwood · Engineer · Sep 30, 2026

Parked vehicles boxed beside driveways from above, landing areas marked, from a customer drone run
On a Saturday at 11 am the store's car park is full, or looks it. Cars circle the near rows, give up, and go to the competitor across the road, while the far corner by the trolley shelter has a dozen empty bays nobody can see from the entrance. The manager counts free bays from the office window when it is quiet and puts a cone at the entrance when it is not. The camera on the lamp post, fitted for security three winters ago, has been recording the whole car park the entire time.
Nobody has asked it how many bays are free, and it can answer that on every frame.
Object detection on vehicles is the easy call and the bay is the hard one
The model's job is small. One class, vehicle, boxed on every sampled frame from the lamp post camera. Object detection on cars from a high fixed camera is about as forgiving as the job gets, provided the model is trained on that camera's own frames, at its angle, with its lens, in its light. A car park model trained on frames from the ground does not see what a lamp post sees.
You type "vehicle" once, Lexi puts a box on every car, van and trolley in every frame, and a person checks the boxes before anything trains. The person's attention goes to the far rows, where two cars nose to tail can read as one long vehicle and a bay between them reads as taken.
Whether a bay is occupied is not the model's call. It is the overlap between a vehicle box and a region drawn on the image, and the region is where the work is.
A region per bay is drawn once and checked against a Saturday
Each bay gets a polygon on the camera's image, drawn by hand, once. A bay near the camera is a clean rectangle; a bay in the far corner is a foreshortened sliver, and the polygon follows the sliver rather than the painted lines the camera can barely see. Occupied means a vehicle box covers enough of the bay polygon, and the fraction is set per row, because the far rows need a lower bar than the near ones.
The set of polygons is then checked against a busy Saturday. A person watches the free-bay count the pipeline produces against the frame it came from, for an hour, and fixes the polygons that lie. There is the one that overlaps the lane so a passing car occupies it, and the two in the far corner that swap when a van parks across the line. My own view is that the hour spent on that Saturday is worth more than any amount of model work, since every wrong count for the next year traces back to a polygon.
The count of free bays, by row, is the product. Everything after that is a rule.
The free-bay count goes to the sign and the manager
The sign at the entrance reads the count and shows it. The manager gets a rule written as a sentence: fewer than a handful of free bays across the car park on a Saturday, routine severity, with a cooldown so the manager is not told every two seconds, approved before it goes live. What arrives is the frame with the occupied bays shaded and the free ones in the far corner marked, which is the same thing the manager was trying to see from the window.
The same count is the front end of a question the store already asks. The traffic counting and conversion use case asks how many shoppers came in and how many bought, and the car park count is the earliest signal in that chain, on a Saturday and on a wet Tuesday alike. The two are watched on the same recorder.
The manager still counts from the window on Saturdays, out of habit, and the two counts get compared. They agree most weeks, and the weeks they do not are the ones worth looking at.
Snow and night glare are the weeks the model doubts
The first hard week is the first snow. The painted lines vanish, the cars are white lumps, and a bay with a snow-covered car in it reads as empty until somebody drives out of it. The second is any winter evening: headlights on wet tarmac throw a reflection down the row that reads as a vehicle on one frame and nothing on the next, and the sodium lamps turn every car the same orange.
The drift catalog files this as rain, fog and dust, and snow belongs on the list: conditions the model rarely saw in training arrive for a week, detection falls off, then it recovers. On a car park the falling off shows up as a count that jumps between frames, and the pipeline holds the last steady count rather than showing the jump on the sign.
LexData takes the car park model through its whole life. You type what to look for, Lexi puts a box on every vehicle in every frame, and a person checks each label before anything trains on it. The model then watches the lamp post camera, in the cloud or on your servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime. The snow frames from January are in the version that watches the car park in February.
A nudged lamp post moves every bay at once
The failure to expect is not weather. In March a tree surgeon's lift brushes the lamp post, and the camera now points a few degrees to the left. The model still finds every vehicle, because a car looks like a car from any angle. The bay polygons have not moved on the image, and the bays have, so the far row's polygons now sit over the lane and the near row's sit over the pavement. The free-bay count goes wrong on every frame, in a way that looks plausible on the sign.
The drift catalog calls it a camera moved, and on a car park it is the cheapest failure to fix and the hardest to notice. The count does not crash. It is simply wrong, by the same amount, all day. What catches it is the manager's window count on Saturday disagreeing with the sign, or a person glancing at the frame behind an alert and seeing the polygons sitting on the lane.
The fix is to redraw the polygons from the new framing, which takes the same hour the first Saturday did, and to relabel a short window of frames from the new angle. Nothing about the model needs starting over.
The window count is the check the sign needs
A car park camera works for a year on the strength of two things: polygons that match the bays, and a person who occasionally compares the sign with what they can see. The first is drawn once and redrawn when the post is knocked. The second is the manager at the window on a Saturday, and the day the two disagree is the day to look at the frame.
See it on your own footage.
Start with your footageMore in Industries

Industries · 6 min read
Perimeter security with fixed cameras, object detection and a drone sent to look
A frame every two seconds is enough to catch a person at the fence, a CPU is enough to run it, and the drone is the second look rather than the detector.
Andreas Ohrvall · Sep 30, 2026

Industries · 7 min read
Food service QA with a camera over the tray packing line
Every component on the tray gets a box, the missing one is flagged before the sealer, and the alert count is read against the line's own history.
Ayman Quadir · Sep 30, 2026

Industries · 7 min read
Railway safety with trackside cameras, zones and a signaller who can live with the alerts
People and vehicles boxed, the track bed and crossing drawn as zones, the frame sent to the control room, and a false alarm rate a signaller will keep reading.
Rajiya Sultana · Sep 30, 2026