Key takeaways
- A count answers how many and where. It does not answer what condition each one is in, and conflating the two is the most common way an inventory project disappoints.
- Imagery counts what is visible from above on the day. Anything under a canopy, inside a building, under a tarp or below grade is not in the count and has to be reconciled from your own records.
- The hard part is the definition, not the counting. Whether a decommissioned unit, a spare sitting on a lay-down yard or a shared pole gets counted is a decision you make before the flight.
- Count error is systematic, not random. Objects get missed in shadow or under vegetation and get double counted at flight line overlaps, so the error has a direction you can check for.
- A count is worth far more with coordinates attached. The same flight that produces a number can produce a point for each item, which is what lets the count load into a GIS or asset register.
- Repeat counts are where the value sits. The first count is a baseline; the second one tells you what moved, what was added and what left, which is usually the question behind the request.
- Resolution has to be chosen for the smallest thing you want counted. A flight planned for pole positions will not reliably resolve individual insulators, and that is a planning decision rather than a surprise.
- An aerial count does not replace a field verification pass. It makes one much shorter, because the crew is confirming a list rather than discovering it.
Counting things is the least glamorous use of aerial imagery and one of the most consistently useful. A client with several hundred kilometres of distribution line, or a yard full of stored units, or a tank farm that nobody has inventoried since it was built, usually knows the number is wrong. What they want is a defensible number and a map.
That is a job aerial capture does well, with some limits that are worth being blunt about before the flight rather than after.
What a count is good for
An aerial count answers two questions at once: how many are there, and where is each one. The second part is the one people underestimate. A number in isolation is an audit fact. A number with a coordinate on every item is the beginning of an asset register, and it loads into whatever system you already use.
The cases where this earns its keep tend to look like one of these:
- Poles, structures and pad-mounted equipment along a corridor, where the line was built in stages and the record was never consolidated.
- Tanks, vessels and skids on a site where the plot plan is older than several rounds of modification.
- Stored units, bins, pipe, panels, rail or equipment in a lay-down yard, where the question is what is actually on the ground against what the system says.
- Solar modules, tables or trackers across a site, usually as a check against the as-built count rather than a discovery exercise.
- Parked fleet and equipment, counted on a fixed date for an insurance, lender or year-end purpose.
In every one of those, the comparison against the client's own system is the deliverable. The count on its own is less interesting than the reconciliation.
The definition work has to happen first
Most of the disagreement about a count is not about the counting. It is about what counts.
A decommissioned structure still standing in the field is either an asset or it is not, depending on which register you are reconciling against. A pole shared with a telecom carrier might belong in your count once, twice or not at all. Spare units stacked in a yard might be inventory rather than installed assets. A tank that is out of service and blanked off is physically present and operationally absent.
None of that is a measurement problem, and none of it can be resolved from imagery. It is a set of rules that has to be written down before the flight, because the count is only reproducible if the rules are. When a client tells us the number came back wrong, roughly half the time the number is fine and the rule was never agreed.
How counts go wrong
Count error from imagery is not random noise. It has specific causes, and because the causes are known, they can be checked.
Occlusion. Anything the sensor cannot see is not counted. Vegetation over a corridor, a structure tucked against a building, equipment under a tarp or inside a shed, anything below grade. This is the dominant error on vegetated corridors and it always undercounts.
Shadow. Low sun angle puts small objects into dark areas where they are hard to resolve. On an Alberta winter flight, with the sun low all day, this is a real constraint and it argues for flying mid-day or waiting for a better window.
Double counting at overlaps. Flight lines overlap by design. An object near the seam can appear in the imagery twice, and if the counting is done across tiles without a spatial dedupe, it lands in the list twice. This one overcounts, and it is the easiest to catch, because duplicates sit within a few metres of each other.
Ambiguity between similar objects. From directly overhead, a transformer and a similar sized cabinet can look alike. Two different tank sizes can read the same if the only cue is the footprint. Where the distinction matters, it needs either an oblique capture or a known attribute from your own records.
Resolution set too coarse. This is a planning failure rather than a counting failure. If the flight was planned at a resolution appropriate for structure positions, individual small components on those structures will not be reliably countable, and reflying is the only fix.
The practical response to all of this is to state an expected accuracy for the count and to verify it on a sample rather than claim it across the whole site. A small area counted independently on the ground, compared against the same area from the imagery, tells you the direction and rough size of the error, and that goes in the deliverable.
A count is not a condition assessment
This is the single most important boundary on the whole exercise, and it is where expectations most often run ahead of what the data supports.
A nadir mapping flight planned for counting gives you position and identity. It does not give you condition. It will not tell you that a pole is rotting at ground line, that a tank wall is thinning, that a connector is running hot, or that a module is cracked. Those are different flights with different sensors, different altitudes and different flight patterns, and in some cases they are not aerial work at all.
Some condition information does come along for free, and it is worth taking: obvious lean, missing or displaced components visible from above, surface staining, ponding around a base, vegetation contact, and anything conspicuously absent. Treat that as a list of things worth looking at rather than as an assessment. If condition is the actual objective, say so at scoping, because it changes the capture substantially.
Turning a count into an inventory
A number in an email has a short life. The version of this that keeps paying is the one that lands in a system.
That means a point for every counted item, in a coordinate system your other data already uses, with a stable identifier and whatever attributes can be read from the imagery honestly. It means the output in a format that opens in what you have rather than in what we have. And it means the reconciliation against your existing register delivered as three lists rather than one: items found in both, items in the register that were not found, and items found that are not in the register.
That third list is usually the one that justifies the project. It is also the one that needs a field check, because a found item missing from the register is either a record gap or a misidentification, and imagery cannot tell you which.
Why the second count matters more than the first
A single count is a snapshot. The question most clients are really asking is a change question: what has been added, what has moved, what has gone. That needs two captures and a consistent method between them.
Consistent means the same boundary, the same counting rules, the same coordinate system and ideally a comparable time of year. If any of those change between captures, the difference you see is partly a method change, and separating the two afterwards is tedious at best.
So if there is any chance this becomes a repeating program, the cheapest moment to fix the rules is before the first flight. A baseline that was flown without that discipline is still useful, but it is a baseline you cannot cleanly difference against.
How to scope one
Four things settle most of the scope. What is the smallest object that has to appear in the count, because that sets the resolution and therefore the flight. What are the counting rules, specifically on decommissioned, shared and stored items. What system does the output have to load into, and in what coordinate system. And is this a one-off audit or the first capture in a series.
If the honest answer to the second question is that nobody has decided, that is worth settling first. It costs a conversation and it is the difference between a count somebody trusts and a count somebody argues with.