Creating an issue
Every issue in WEXWatch starts with a photograph. You do not place a pin by clicking the map: you upload a photo and WEXWatch places the pin using the coordinates stored inside the photo.
The geotagged photo requirement
A photo must contain GPS coordinates in its EXIF metadata. A photo without them is rejected, and no issue is created.
This is deliberate. The location of an issue is the most important thing about it: it determines who owns the asset, who is responsible for fixing it, and whether a later inspection is looking at the same place. A coordinate captured by the camera at the moment of the photograph is evidence. A pin dropped by hand afterwards is a recollection, and recollections drift — especially along a corridor where one length of kerb looks much like the next.
Keeping the requirement absolute also means every pin on the map has the same provenance. You never have to wonder whether a particular issue was positioned accurately.
Supported formats and size limit
| Property | Value |
|---|---|
| Formats | JPEG, PNG, WebP, HEIC and HEIF |
| Maximum size | 25 MB per file |
In practice, use JPEG or HEIC straight from the camera or phone. Those are the formats that carry GPS metadata reliably. PNG and WebP are accepted, but images in those formats usually have no EXIF GPS at all, because they are typically produced by editing or exporting — which is exactly the step that strips the metadata.
A file larger than 25 MB is rejected. Full-resolution photos from a phone are comfortably under that.
Adding photos
Start a new issue from the create action, then either drag photos onto the drop area or click it to browse for files. You can add several photos at once, and add more afterwards.
Each file is checked in the browser as it is added. Files with no GPS metadata are reported immediately, by name, so you know which ones to re-take or re-transfer.
The draft queue
Accepted photos stack up as drafts, each with its own small form. Nothing is stored on the server yet.
While a photo is a draft:
- A provisional pin appears on the map at the photo's coordinates, drawn smaller and lighter than a saved issue, so you can confirm the position looks right before committing.
- The draft shows the coordinates read from the photo, in both WGS84 and NZTM, along with the ground elevation where it is available.
- You can remove a draft to discard it. Nothing is kept.
- Double-clicking the thumbnail enlarges the photo, which is often necessary to identify what you actually photographed.
Drafts are separate from saved issues. If you close the dialog the drafts survive, but they are not part of the project register until you save them.
The fields
Name. A short description of the issue, used as the map label and in lists. It defaults to the photo's file name with the extension removed, which is rarely what you want — replace it with something a colleague would understand, such as "Kerb displaced outside 12 Great South Road". Up to 200 characters.
Nearest Address. Filled in automatically from the photo's coordinates and always editable. It is the nearest addressable point, not necessarily the property responsible for the issue, so correct it when you know better. As you type, address suggestions appear and can be selected. Up to 300 characters. See Addresses, coordinates and elevation.
Issue type. The category of defect or observation:
| Issue type | Use for |
|---|---|
| Unclassified | The default. Something worth recording that has not been categorised yet. |
| Kerb | Kerb and channel: displacement, cracking, damage, missing sections. |
| Drainage | Sumps, culverts, catchpits, ponding, blocked or damaged drainage. |
| Signage | Signs and posts: missing, damaged, obscured, incorrect. |
| Pavement | The running surface: potholes, rutting, cracking, edge break. |
| Fencing | Boundary and safety fencing. |
| Other | A real category that none of the above cover. |
Leaving something as Unclassified is better than forcing it into the wrong category. It can be changed at any time.
Recorded on Site Date. The date the observation was actually made in the field. It is seeded from the photo's capture time where the photo carries one, so usually you only need to check it. Correct it if the photo's clock was wrong, or set it if the photo carried no capture time.
This date is distinct from when the issue was uploaded. A photo taken on a Friday and uploaded on the following Monday should read as Friday, because that is when the condition was observed. Reports and any argument about how long a defect has been present depend on this field, not on the upload timestamp.
Notes. A free-text description of what you are looking at and why it matters: extent, severity, access, hazards, anything a person who was not there would need. Up to 5,000 characters. This becomes the issue's description, and appears in the map popup preview.
Saving
Save each draft individually, or save the whole queue at once when you have several photos. Each save uploads the photo, creates the issue, drops the pin and starts the issue's timeline with the upload event.
New issues are created with the status Open.
If a save fails, the draft stays in the queue with the error shown, so you can fix the cause and retry rather than losing your typing.
Taking photos that will work
- Turn on location services for your camera app before you go on site, and check that photo location tagging is enabled. This is the single most common cause of rejected uploads.
- Give the phone a few seconds to get a GPS fix after you arrive, particularly the first photo of the day.
- Photograph from a position that shows the defect and enough surrounding context to locate it again.
- Send photos to yourself in a way that preserves metadata. Some messaging apps and social platforms strip EXIF, and some email clients offer to shrink images, which does the same thing. Transferring the original file, or uploading directly from the phone, avoids the problem entirely.