Location accuracy in condition records: useful context with limits

A return photo might say Location recorded (approximate, ±65m). Another image on the same record might carry older coordinates from its file metadata. Both contain location, but they describe different events.

That distinction matters more than the pin. Before relying on location accuracy in a condition record, check how the location entered the record, which precision class accompanied it, what meter value the phone reported, and whether the person receiving the record actually needs the exact coordinates.

Location can help someone review a photo. It cannot turn a phone reading into a land survey or show, by itself, where an asset was when damage occurred.

Start with the source, not the map pin

For a live camera photo, AuditIt can store a location fact from a device fix associated with that capture. The fact keeps the platform precision class and, when supplied, the phone-reported accuracy in meters. Current precision values are precise and platform_approximate.

Approximate does not mean that location is missing. It means the platform supplied a rounded location grant. AuditIt keeps that class visible, and its current watermark can show Location recorded (approximate) or Location recorded (precise), followed by rounded ± meters when the phone provides an accuracy value. AuditIt records that value; it does not sharpen the phone's fix.

A gallery import follows a different path. AuditIt does not add the importing phone's current location to an existing file. If organization policy allows location and the selected file contains a complete coordinate pair with a fix time, those coordinates can be kept as source metadata and labeled platform_approximate. They describe the imported file, not the place where someone tapped Import.

If you need the broader distinction among live capture time, import time, and file metadata, read capture facts vs import facts.

What the ± meters label tells a reviewer

AuditIt's meter value is the accuracy reported by the phone. Read it beside the precision class and the source. A coordinate without those labels invites more confidence than the record supports.

The W3C Geolocation specification offers useful context, with an important boundary. In its 26 March 2026 Candidate Recommendation Snapshot, accuracy is a radius in meters and the acquired value is described at a 95% confidence level. That is the W3C web-API definition. It is not a measurement of AuditIt's mobile stack, and this article does not treat an AuditIt ± meters label as a 95% confidence claim.

The same specification calls a high-accuracy request a hint: the device may still return no improvement. AuditIt likewise cannot convert an approximate platform grant into a precise fix. The phone and its settings control what is supplied.

Consider a fictional compact excavator returned with a bent bucket tooth. One live photo shows an approximate device fix with ±65m. An imported gallery photo carries source-metadata coordinates from earlier in the day. The live fact helps place the phone within its reported context; the gallery fact helps explain the file's history. Neither reading establishes where the tooth bent.

That is the practical limit. Location supports the review; photographs, notes, timestamps, and the wider record still carry the rest of the story.

Four questions worth asking

1. Where did this location come from? Look for device_fix on a live capture or source_metadata on a gallery file.
2. How was it labeled? Keep precise and platform_approximate distinct.
3. Did the phone report an accuracy value? Read the ± meters label as reported context, not a surveyed boundary.
4. Who needs the exact coordinates? Share them only when they are necessary for the recipient's task.

These questions keep the mechanics separate from the conclusion. A reviewer can use the location to understand how the record was assembled without asking the coordinate to decide cause or responsibility.

Share exact location deliberately

Location often reveals more than an equipment position. The W3C privacy section observes that retrieving a device's location will usually disclose the user's location as well, and its guidance asks recipients to request position information only when necessary for the task. That is web-API guidance, not equipment-hire law or a privacy compliance checklist, but the minimization principle is useful.

AuditIt's public-share control follows a clear choice: Show exact capture location is off by default. Turn it on only when the authorized recipient needs exact coordinates and capture accuracy. Selecting photographs or a PDF does not switch location sharing on.

For a handover, that may mean sharing exact location with an internal reviewer investigating where photos were taken while leaving it off a customer-facing link that only needs the condition views. The right choice depends on the task and the people authorized to see the coordinates.

Where AuditIt fits

AuditIt can keep a live device fix or eligible source-metadata coordinates beside the relevant photo, together with the source, precision class, and phone-reported accuracy. That gives a reviewer more context about what was submitted and how it entered the record.

The boundary is straightforward: AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability. A person still has to decide what the photographs and the rest of the record mean.

For the integrity checks available on a shared record, see what AuditIt public report verification checks. For a consistent photo routine, see repeatable equipment condition photos.

To start a structured condition record, create an AuditIt account.

• location accuracy
• condition records
• capture facts
• privacy
• approximate location