Software when we need it
- Roger Erismann
- May 11
- 3 min read
Hammerdirt’s work starts in the field. Trees have to be seen in context: where they are growing, what they are near, how people use the site, what condition they are in, and what kind of work, if any, is appropriate. That is not something we wanted to force into a rigid software template.
So we developed our own software. Our team includes a data scientist with experience in developing client applications and a Master arborist.

How we use our software: To enable informed decisions we need to collect a variety of information
Inventories and detailed assessments
Hammerdirt’s system includes both inventory tools and detailed assessment tools.
For inventories, TRAQ Field Inventory is a local-first Flutter app used to record tree inspection work in the field. It stores job data as portable JSON, copies images into a job folder, and supports export from the device so the folder can be moved to a computer later.
That app is organized around jobs and tree records. A tree record can include identity, images, measurements, risk, treatment, estimate, location, and notes. It also supports practical field needs such as DBH/DSH measurements, images from the camera or gallery, GPS location, custom species entries, treatments, risk, residual risk, and work priority.
For trees that require a more detailed inspection, TRAQ Observer supports a different workflow. It collects recordings, photos, GPS data, and TRAQ form edits in the field, sends work to the TRAQ server for review, receives drafts and transcripts, and exports final TRAQ and report PDFs for completed jobs.
Those are different use cases. The inventory app helps us move efficiently through many trees. The TRAQ Observer workflow supports detailed, section-based assessment and review when a tree needs that level of attention.
Structured data from the beginning
The inventory workflow uses a standardized JSON structure: jobs, tree records, measurements, locations, controlled values, and images each have defined places in the export. The app also validates key fields before writing data, including tree number, risk, residual risk, work priority, DBH/DSH values, coordinates, relative image paths, and image count per tree.
That structure is what makes LLM-assisted structured generation more reliable. Instead of asking a model to infer species, measurements, risk, treatments, locations, and notes from a block of prose, the model receives typed fields with predictable meanings. It can then generate summaries, report sections, QA checks, or formatted outputs from known inputs rather than inventing the structure itself. The TRAQ server follows the same principle: field observations are converted into structured assessment data using a canonical TRAQ mapping and validated extraction utilities, so outputs remain consistent and machine-usable.
Exports for reporting, mapping, and analysis
The export workflow is intentionally simple. data.json is the source inventory export. Scripts read that file, normalize each tree record, and generate different outputs from the same source data.
Current outputs include a full tree report PDF, a report filtered to trees with recorded work, a tree report CSV, and a QGIS map CSV. The report CSV includes tree ID, tree number, species, DSH, hours, work priority, risk, and treatments. The QGIS file includes latitude, longitude, species, risk, hours, work priority, and tree number, with coordinates written at full precision for mapping.
This gives us flexibility. The same field collection can support a written report, a work specification, spreadsheet review, GIS mapping, or database import. For clients using spatial databases, the structured and georeferenced data can also be shipped as a GeoJson object.
Built by the people using it
In our team we have an ISA Master Arborist, a Data Scientist and an ISA Arborist. While the Arborist determines what needs to be observed, assessed, and prescribed. Data and software design determine how those observations are stored, validated, transformed, mapped, and reported.
The result is a system that can change as the service changes. If a project needs a different report format, a different export, a new field, a GIS layer, or a workflow for detailed TRAQ assessment, the software can be adapted around the work instead of forcing the work into the software.
The practical result
For Hammerdirt, the software is part of how we provide tree management services. It helps us work more efficiently in the field, keep observations structured, support ISA TRAQ-style assessment where appropriate, and deliver data in forms that clients can actually use.
Comments