Aerolytics: aerial data analysis for utility networks.
A platform for a North American utility-sector operator that collects data over network assets from the air and turns it into something an engineering team can act on. Built with Python, Django, Django REST Framework, Celery, Angular, Angular Material and Leaflet.js, it moves inspection work from photographs on a laptop to a queryable, mapped record of the network.
The challenge.
- Aerial inspection produces very large volumes of imagery and sensor data per flight — orders of magnitude more than anyone will review by hand.
- The value is not in the capture but in the association: every observation has to be tied to the specific asset it belongs to before it means anything operationally.
- Processing is slow and bursty by nature, so it could not sit in the request path without making the application feel broken.
- Field and inspection staff needed to work with results geographically rather than as rows in a table, because a utility network is a spatial object before it is a database.
Our approach.
- Built the ingestion and processing pipeline in Python, with Celery carrying the heavy per-flight work so that uploads and analysis run as tracked background jobs rather than blocking anyone.
- Modelled assets, inspections and observations in Django as first-class entities, so an observation is permanently attached to the asset and the flight that produced it.
- Exposed everything through Django REST Framework, keeping the processing pipeline and the interface cleanly separated so either can change without breaking the other.
- Built the operator interface in Angular with Angular Material, designed for reviewing long queues of findings without fatigue rather than for demo screenshots.
- Put Leaflet.js at the centre of the experience so the network is explored on a map, letting a user move from a region to a single asset's inspection history in a few interactions.
The outcome.
- Inspection output becomes a queryable record of the network rather than a folder of imagery.
- Heavy processing runs as visible background work, so the application stays responsive during large ingests.
- Findings are explored geographically, which matches how the people using it already think about the network.
- Each asset carries its inspection history, so change over time is visible instead of being reconstructed from memory.
Where AI fits in energy & climate.
Turning field notes and inspection reports into structured records, assistants that answer questions over asset and sensor data, and first drafts of regulatory reports.
Explore AI developmentQuestions about this build.
Still wondering something? Ask an engineer
The first design decision is to get processing out of the request path entirely. Ingest accepts the data and returns immediately; the actual analysis runs as background jobs with visible state, retries and failure handling. Here that is Celery over a Python pipeline. The second decision is to make every processed observation permanently traceable to its source capture, because unattributed findings cannot be trusted or re-checked later.
By treating the asset as the centre of the data model rather than the capture. Each observation is attached to a specific asset and to the flight or survey that produced it, so an asset accumulates a history rather than existing as a series of disconnected reports. This is what makes questions like whether a condition is new or has been slowly worsening answerable, which is usually the actual operational question.
Because a utility network is spatial before it is anything else, and its operators navigate it geographically. Leaflet.js gives the interface a map-first structure where a user can move from a whole region to one asset's inspection history in a few steps. A table can express the same data, but it forces the user to translate between how the system presents the network and how they actually hold it in their head.
It depends on how much of the processing pipeline already exists and how clean the asset data is going in. In our experience the interface is rarely the long pole; reconciling asset records and defining what counts as a reliable observation usually takes longer than expected. We scope that discovery explicitly rather than assuming the existing asset register is accurate, because it very often is not.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.