Photo Documentation
That Holds Up

A written condition note — "moderate decay, southwest side of stem" — is useful. A photo of that decay, taken the day of the survey, is the thing that actually holds up months or years later if a client, insurer, or planning officer questions the assessment. Notes get reinterpreted with time; a photo dated to the survey day doesn't.

This matters most on the tree that ends up mattering most — the one flagged for risk, the one a client wants removed but a neighbour disputes, the one that fails after your visit and everyone wants to know what state it was in. You don't know in advance which tree that will be, which is the argument for a consistent minimum photo standard applied to every tree, not just the obviously risky ones.

There's also a simple time-of-year argument for consistency: if a tree is reinspected a year later, comparing this year's photo against last year's is far more useful when both were taken the same way, from roughly the same angle, at a similar time of year. An inconsistent photo record makes year-over-year comparison a guessing exercise.

The baseline, for every tree regardless of condition:

For any tree with a defect or condition worth noting — decay, cavities, cracks, codominant stems with included bark, deadwood, lean, pest or disease signs, root damage — add a close-up. Frame it so the defect is legible at normal zoom, not a distant blur that needs the viewer to take your word for what they're looking at. If there's a scale reference handy (a tape, a hand, a known object), include it — it turns "significant cavity" into something a reader can judge for themselves.

For a tree carrying a risk rating, the photos are effectively part of the assessment record, not decoration. If the rating is ever challenged, the photo of the actual defect is stronger evidence than the written description of it.

Multi-stem trees need a photo per stem where condition differs between stems — a single wide shot of the whole multi-stem tree doesn't show which stem has the included bark or the decay if that detail only applies to one of them. Frame the close-up so it's obvious which stem is which, especially if you're also recording per-stem DBH and condition separately.

A photo with no clear connection to a tree number is close to useless in a multi-tree survey. The connection has to be made at capture time, standing at the tree — not reconstructed later from memory or timestamp order, which is exactly where surveys lose accuracy on long jobs.

Whatever method you use — a paper note logging "photos 14-16 = tree 22," a dedicated folder per tree, or an app that attaches photos directly to the tree record — the requirement is the same: by the time you leave that tree, the link to its number has to already exist. Deferring it is the single most common cause of photo-to-tree mismatches in the final report.

This gets harder, not easier, on a large site. On a 10-tree residential job you can probably reconstruct photo order from memory if you had to. On a 200-tree municipal inventory spread across several visits, memory isn't a fallback — the link either exists at capture time or the photo is functionally lost to the report, even though the file itself is sitting right there on the device.

A useful naming convention has the tree number in the filename itself, not buried in a folder structure or a separate index that can get separated from the photos. Something like Tree-047_photo1.jpg survives being copied, zipped, emailed, or dropped into a shared drive intact — the tree number travels with the file no matter what happens to the folder it started in.

A camera roll full of IMG_4521.jpg through IMG_4987.jpg does not survive that journey — the moment the sequence gets reordered, split across devices, or handed to someone else, the tie back to a tree number is gone.

For multi-stem or panorama-type records, keep the type in the name too, not just the number — a "12" that could mean tree 12, multi-stem tree 12, or panorama 12 is exactly the kind of ambiguity a naming convention exists to prevent. Distinguish them explicitly rather than relying on the reader to guess from context.

Not every useful photo belongs to a single tree. A wide shot showing the general layout of a section of the site, a reference photo of an access point, or a shot documenting an area too dense to assess tree-by-tree all serve a purpose the report needs, without being tied to one specific tree number.

Keep these separate from your per-tree photos rather than force-fitting them onto whichever tree happens to be nearest — a wide-context shot pinned to "Tree 14" when it's actually documenting the whole northeast corner of the site creates exactly the kind of ambiguity that undermines a report months later. If your workflow supports a distinct pin or record type for this kind of wide reference photo, use it rather than overloading a tree record with something that isn't about that tree.

This is the most common photo-documentation failure, and it's not a technique problem — it's a sequencing problem. Photos get taken in the field, on the phone's default camera app, into the general camera roll. Back at the office, sorting 200 trees' worth of photos into the right buckets by memory and timestamp is slow and error-prone, and it's the step most likely to get rushed or skipped under deadline pressure.

The fix isn't a better sorting method after the fact — it's not creating the sorting problem in the first place, by tying each photo to its tree number the moment it's taken.

A related version of the same problem: photos taken on a personal phone that then need transferring to a work computer, uploading to a shared drive, and re-sorting a second time before they reach the report. Every extra transfer step is another chance for a photo to lose its context, get duplicated, or simply get missed. The fewer hops between "photo taken" and "photo filed correctly," the fewer things can go wrong.

Photos in LogLog attach directly to the tree record you're standing at — there's no separate camera roll step and no later matching by memory. Multiple photos per tree are supported, so a full-tree shot and a defect close-up both live on the same record without any extra bookkeeping.

On export, photos are named automatically by tree number and type — Tree-047_photo1.jpg, Multi-012_photo2.jpg, and so on for panorama pins too — inside an images/ folder in the ZIP. You never touch a filename by hand.