Photo and data handling
It is worth knowing what WEXWatch does with a photograph, because the answer affects what you can rely on later.
What happens when you upload
- The file is checked against the accepted formats and the 25 MB limit.
- Its EXIF metadata is read. If there are no GPS coordinates, the upload is refused and nothing is stored.
- The coordinates are converted from WGS84 to NZTM2000.
- The original file is kept, byte for byte. It is not recompressed, resized or stripped.
- Two smaller copies are generated for display: a thumbnail around 480 pixels on its longest edge, and a detail copy around 1,600 pixels, both in WebP.
- A SHA-256 checksum of the original is recorded, so it is possible to prove the stored file is the file that was uploaded.
- The issue is created, the pin appears, and the upload becomes the first entry on the issue's timeline. A separate audit record is written at the same time.
The original matters. Derivatives exist so the map and lists stay quick on a mobile connection, but an inspection photograph loses the fine detail — hairline cracking, surface texture, the exact line of a displacement — as soon as it is recompressed. When you open a photo at full size you are looking at the original, not the reduced copy.
Alongside the file, WEXWatch records the image dimensions, the file sizes, the original format, who uploaded it and when.
What is read from EXIF
Two things are used directly:
- GPS coordinates, which position the pin. Mandatory.
- Capture time, which seeds the Recorded on Site Date so you normally only have to confirm it. Optional, and easy to correct.
The rest of the photo's metadata is retained with the record rather than discarded, which is what makes it possible to answer later questions such as which device took a photo.
How photos are shown
Photos are served through WEXWatch itself rather than from public links, so viewing them goes through the application. There is no public URL you can paste into an email that will show a photo to somebody who does not have access — send them the issue instead.
Where the data lives
Issue records, timelines, coordinates and the audit trail are held in a PostgreSQL database with the PostGIS extension, which is what makes the spatial queries possible. Photo files are held separately in private storage rather than in the database.
Data is separated by organisation and by project. Requests are always filtered to what your organisation and project are entitled to see, rather than relying on the interface simply not offering a link to something else.
If you need to know exactly where a particular deployment is hosted, who administers it, and what the backup and retention arrangements are, ask the programme administrator — those are deployment decisions rather than features of the application.
The audit trail
Alongside the timeline that you read and write, WEXWatch keeps an append-only audit log. Creating an issue, editing its fields, uploading a photo and adding a note are all recorded with the user who did it and when.
The audit log is written by the application and is not editable from the interface, including by administrators. Its purpose is to answer "who changed this, and when" months later, without depending on anyone's memory.