Linking GIS, Asset Systems and Tree Records

A typical council holds tree-related data in at least three places. The GIS team maintains a tree layer. The asset team maintains tree records in the corporate asset management system. The parks team maintains an operational record — sometimes in a tree management system, sometimes in a spreadsheet, sometimes in a consultant's deliverable.

Each of these is doing something different. The trouble starts when one of them is asked to do all three jobs, or when the three drift out of sync.

What each system is for

GIS is for spatial reference: where the tree is, what it relates to in space (kerb, footpath, road reserve, property boundary), and how it appears on maps. Its strength is the spatial dimension. Its weakness is operational data — condition history, inspection notes, work orders and evidence sit awkwardly inside GIS attributes.

The corporate asset management system is for asset accounting: the tree as a financial and lifecycle asset within the broader asset register. Its strength is integration with finance and lifecycle reporting. Its weakness is field-level operational data — most asset systems are not designed for inspectors and contractors to update in the field.

The operational tree record is for day-to-day operations: current condition, inspection history, defects, risk, work orders, contractor evidence and resident requests. Its strength is the operational loop. Its weakness is that it is often not the system the asset team or GIS team sees.

The relationship that works

A workable relationship between the three is roughly:

• GIS holds spatial reference and a thin set of attributes (asset ID, species, broad type)
• The operational record holds the full operational data
• The asset management system holds the financial and lifecycle data and references the operational record for current state
• All three share an asset ID

Each system retains responsibility for what it is good at. The shared asset ID is what makes the three views coherent.

The relationship that breaks

The relationship breaks when one system is treated as the source of truth for fields it is not designed to hold. The two most common patterns:

• GIS becomes the operational record. Field staff update condition and risk through GIS attribute edits. The asset and parks teams use GIS as the working register. Over time it accumulates fields it was not designed for, performance degrades, and field updates become slow.
• The asset management system becomes the operational record. Inspectors are asked to update tree records in the corporate system through office workflows. Field activity stops updating the record. The asset team reports look clean but bear little relationship to field reality.

Both fail in the same way: a system optimised for one thing is asked to do another, and quality drops in both.

How to start untangling

Most councils do not need to rebuild any of the three systems. They need to clarify which fields each owns. A short exercise that helps:

• List the operational fields tree management requires (location, species, condition, risk, inspection history, works, evidence, requests, next action)
• For each field, name the system that owns it
• For each field, name the systems that read from it
• Identify any fields where ownership is ambiguous and decide

Done in an afternoon by the parks, asset and GIS leads together, this exercise typically surfaces the disagreements that have been quietly causing data quality problems for years.

A practical heuristic

A useful rule of thumb: spatial reference belongs in GIS, financial and lifecycle in the asset system, operational state in the operational record. Where systems blur these boundaries — usually because no other system was available at the time — moving each field back to its natural home, even slowly, usually improves data quality across all three.