Why do forest operations keep their maps and their numbers in different systems?

Because a stand on a map and the numbers about it relate one to many. One stand has many loads, several settlements, perhaps more than one contract and years of costs. A GIS layer shows one row per shape, and an ERP or scale system holds one row per transaction. GIS can relate one shape to many records, but to show them as one figure per stand, someone has to summarise them by a rule. Joined without that rule, the numbers can be dropped or counted twice, with no warning on the map. And often the transactions don't carry the stand's key at all. The two stay apart less because of vendors or habit than because joining them needs a shared key and a written rule.

What the usual answer says

Nothing that ranks for this question answers it. The top results are an FAO guideline on defining forest resources, a history of national forest mapping and an encyclopedia entry on forest management. The common explanation elsewhere is that maps and financial data were built by different vendors for different people, GIS for foresters and planners and ERP for accountants, and that integration tools now bring them together. That history is real. It does not explain why the join is hard even when both systems are modern.

What the GIS documentation says about joins

Esri's documentation for ArcGIS Pro sets out how a table of numbers attaches to map features. "Through a common field, known as a key, you can associate records in one table with records in another table," the page on joins and relates explains. Its example is a table of parcel ownership joined to a parcels layer by a shared identifier.

The same page describes what happens when one feature matches many records. "If you are using data in the same geodatabase to create the join, all matching records are returned. If you are using nondatabase data, such as shapefiles or dBASE tables, to create the join, only the first matching record is returned." For one-to-many data it recommends a relate or relationship class instead. Its own worked example summarises county figures by state first, and then joins the summary to the state layer.

For a forest business the implication runs both ways. Join a table of loads to a stand layer held as a shapefile, and each stand may show only its first load. Join it to a stand layer in a geodatabase, and in our reading each stand appears once per load, so anything summed per stand from the joined table, such as its area, is counted many times. Either way the map looks complete and the figure on it is wrong.

One stand, many records

The numbers side is one-to-many too. From Quarri's own work with a forestry operation: one release cycle matched 1,400+ bills of lading across 70+ invoices, with every rated row and every eligible weigh record accounted for. In general, a stand has many loads and an invoice covers many of them, so a map that shows one figure per stand is showing a summary, and someone has to decide how that summary is made.

That decision is the real reason the two stay apart. The GIS specialist owns the shapes, finance owns the transactions, and nobody owns the rule that turns many transactions into one figure per shape.

The missing key

Often the harder problem sits upstream of the GIS. A scale ticket or a settlement records a contract or a sale, and may carry no stand identifier at all. Where that is so, there is nothing to join on, and no join setting fixes it. Capturing the stand or sale key on the ticket is then the first step.

How to join them properly

Keep each kind of data in the system built for it. Give every transaction a stable key that the map also uses, such as the stand or sale identifier, spelled the same way in both. Summarise the transactions per key by a written rule: which records count, over which dates, in which unit. Join the summary, one row per shape, to the map.

Keys need looking after. An FAO guideline on defining forest resources, from 1998, describes the compartment as "a permanent, geographically recognisable unit of forest land forming the basis for planning, prescription, implementation, monitoring and recording of forest operations". The word that matters for data is permanent. A key that changes on the map but not in the transactions, after a stand is split or renumbered, breaks the join without anyone noticing. A record of which old identifiers became which new ones keeps history attached to the right ground.

When it doesn't apply

Attributes that are genuinely one per shape, such as a stand's planting year, species or soil class, join directly and belong on the map. Very small operations with a handful of stands can keep a summary table by hand. And a spatial join, which matches features by location rather than by key, is useful where no shared identifier exists, though it inherits every error in the boundaries. In a 2026 benchmark of AI agents on GIS tasks, tasks tagged with geometry and topology errors were completed only 15.2% of the time, and those with mismatched coordinate systems 22.0%, the worst of any category.

Quarri for forest management is built around how a forest operation runs, from the cruise to the settled account.

Quarri is an AI-native data platform for the timber supply chain. It connects buying, production, sales and inventory for forest management, sawmill, wood products and pulp, paper and packaging operators.