What Data Should Councils Capture During Tree Inspections?

An inspection that does not change the tree record is mostly paperwork. The point of a tree inspection is to update the operational state of the tree — its current condition, its identified defects, its risk rating, its recommended actions and its next review date.

That sounds obvious. In practice, many inspection programs collect long lists of fields, only a few of which actually flow back into the asset record. Useful inspection design starts by asking: which of these fields, if updated, would change what the council does next?

The fields that almost always matter

A reasonable inspection should always capture:

• tree identifier (existing asset ID where possible)
• date of inspection
• inspector identity
• inspection method (visual / level 1 / level 2)
• current condition rating
• identified defects (with severity)
• risk rating, using the council's chosen framework
• recommended actions and target timeframes
• next inspection date
• supporting photos and GPS

These fields are what later allow the team to filter, sort and act. They are also what stand up under audit or complaint review.

The fields that are useful but not always essential

Some additional fields add value when a council has the discipline to maintain them:

• structural details (DBH, height, canopy spread)
• target zone or use of surrounding space
• soil and root environment notes
• arboricultural observations beyond defects (vigour, foliage, recent works visible)
• whether the tree is part of a notable cohort (heritage, memorial, signature avenue)

These fields are most valuable when they help differentiate between trees with otherwise similar surface ratings.

The fields that often get collected and never used

Many inspection forms drift toward completeness rather than usefulness. Common examples of low-value fields:

• categorical fields with overlapping definitions
• free-text fields where structured tags would do
• fields that duplicate something already in the GIS layer
• fields recorded once and never referenced again

If the team cannot point to where a field is used in decisions, the field probably should not be required.

Designing the form around the record, not the other way round

The most reliable test for an inspection form is to map every field to a destination on the tree record. If a field has no destination — no place where it updates the asset, triggers a work order, changes a risk rating, or feeds a report — it is filler.

Forms designed this way tend to be shorter, faster to complete in the field, and more likely to produce inspections that actually change what the council does next.