Workflow7 min read27 February 2026

The Site Photo Problem: Why Engineers Can't Find Their Survey Photos

Most engineering practices have thousands of site photos stored somewhere they can't search properly. Here's why the standard workarounds fail, and what actually helps.


Every structural engineer and surveyor has been here: you did a condition survey eight months ago, you took thorough photographs, and now a client is asking about a specific wall junction you know you photographed. The photos are in a project folder somewhere. There are 340 of them. They're named IMG_0847 through IMG_1187. You'll find it — you just need ten minutes to scroll through them.


The Photos Exist. Somewhere.

This is the site photo problem. It's not dramatic. It's just friction, accumulated across hundreds of projects and thousands of images, quietly consuming engineering time that could be spent on something else.

You come back from site with 200 images. They're vaguely named, stored in a folder, and your ability to find “the shot from the boiler room that shows the pipe support” six weeks later depends entirely on your memory.


How Most Practices Currently Handle It

The Named Folder System

The most common approach: create a folder structure that mirrors the building, and put photos in the right subfolder as you import them.

Project 2847 - St Andrew's House/
  Photos/
    Level 1/
    Level 2/
    Roof/
    External/

It works, up to a point. Someone has to do the sorting. If you're the person who took the photos and you do it immediately on returning from site, it's manageable. If the photos sit in a camera dump folder for three days and then someone else processes them, the accuracy degrades quickly.

The other issue: “Level 2” is a location category, not a location. You still can't find “the crack near the east stairwell” without looking through everything in the Level 2 folder.

SharePoint and Dropbox

Cloud storage solved the accessibility problem — anyone on the team can get to the photos from anywhere. It didn't solve the organisational problem. SharePoint is, functionally, a folder system with a web interface. The photo lives somewhere in the folder hierarchy, and finding it still depends on how carefully the hierarchy was maintained.

SharePoint does have metadata tagging and search functionality, but in practice most engineering practices don't configure or use it. Photos get uploaded into folder paths and that's where the system ends.

OneNote and Notion

Some surveyors create a OneNote or Notion page per project, embed photos inline, and write notes alongside them. This is genuinely better than pure folder storage for documentation purposes — the context stays with the image.

The limitation: it doesn't scale. A page with 300 embedded photos is slow to load and difficult to navigate. Notion adds a database layer that can help, but that requires someone to tag everything consistently — the same manual discipline problem as careful folder naming.

The Spreadsheet Index

Some practices maintain a spreadsheet alongside the photo folder: filename, date, floor, room, brief description. It's painstaking but it works if maintained properly.

The problem is that it requires double-entry discipline. In busy practices, this discipline deteriorates. Spreadsheets get abandoned half-complete. The oldest entries are thorough; the recent ones aren't.


Why None of These Fully Work

All of the above are attempts to impose a retrievable structure on a collection of inherently spatial objects, using tools that aren't designed to handle spatial data.

A photograph taken in Room 3B on Level 2, near the north window, adjacent to the structural column — that's a location. The information that makes it retrievable is its physical position in the building. Every workaround above tries to encode that location as text (a folder name, a spreadsheet cell, a page title) rather than storing it as what it actually is: a coordinate on a plan.

When you've encoded location as text, retrieval requires you to remember the text encoding you used. Did you call it “Level 2 Room 3B” or “2nd Floor East Office” or “F2-3B”? Whatever naming convention you used in a hurry on a busy site day six months ago — that's what you need to remember now.


What the Problem Actually Is

The core issue is the gap between capture and context.

You capture on site with good spatial awareness — you know exactly where you are when you take each photo. The challenge is transferring that spatial awareness into the storage system in a way that survives the passage of time and the involvement of other people.

What would actually solve the problem: a system where the photo is stored at a specific location on the building's floor plan, so retrieval means navigating to that location rather than searching through a text index.


Emerging Approaches

Spatial Indexing

Spatial indexing means attaching images to locations on a plan, rather than filing them in a folder tree. When you're looking for “the east stairwell on Level 2,” you navigate to that location on the plan and see the photos taken there.

This is the principle behind tools like OpenSpace and HoloBuilder in the construction sector. For surveys of existing buildings, a lighter-weight approach makes more sense. pin360 takes that direction: you upload your existing PDF floor plan, drop pins at capture locations, and attach your 360° photos. The floor plan becomes the navigation interface.

It's a simpler system than the enterprise construction tools, which makes it quicker to use and easier to hand to a client or colleague who hasn't been on site. pin360 is is live and open for new teams at pin360.io.

AI-Based Search

A separate emerging approach: using AI to search photo content directly — tools that can analyse a folder of images and answer queries like “show me photos with visible cracking.” The limitation is that “find photos near the east stairwell” is a spatial query, not a visual content query. Spatial indexing and AI search solve different parts of the problem.


Practical Steps You Can Take Now

Without investing in new software, a few things materially improve photo retrievability:

  • Adopt a location-based naming convention on site, not afterNumber photos in sequence but use a prefix that encodes location — L2-E-001 for Level 2, east area, photo 1. Do this before you leave site.
  • Take a photo of your floor plan before you startA simple shot of the drawing with a marker showing where you started gives you a reference point when trying to reconstruct the sequence later.
  • Use a reference gridDivide the floor plan into named zones — A, B, C, or grid references. Capture in zone order and name files accordingly.
  • Keep 360° and standard photos separate360° images and standard photos mixed together in the same folder double the work of finding anything.
  • Document as you go, not at the endIf you're using a site inspection app or tablet, attach photos to the inspection item immediately on site.

None of these are revolutionary. They're process discipline — which is why they're difficult to sustain across a busy practice. The longer-term answer involves systems that don't depend on discipline: spatial indexing where location is captured at the point of pinning rather than encoded into a filename by someone who may not remember the convention.

The photos exist. Somewhere. The goal is to build a system where “somewhere” has a specific, retrievable answer.