An offline QField project is prepared on the desktop before departure: data, basemaps, forms, identifiers and synchronisation rules must work without a signal. Installing the application on a phone does not resolve conflicts, quality or data recovery.
The official QField documentation explains that QGIS projects can be used online or offline and must be packaged for the device. The local-transfer workflow with QFieldSync creates a working copy, tracks changes and synchronises them afterwards. The documentation also warns that its cable workflow does not provide automatic conflict handling; that responsibility belongs in the operational design.
Draw the field day before the form
Describe what a team receives, what it can observe, which decisions it makes offline and who reviews the return. Turn that journey into simple states such as assigned, started, incomplete, submitted, queried and approved, according to actual needs. Require each field because it supports a decision; a long form does not equal a complete database.
Configure value maps, ranges, dependencies and defaults in QGIS. Make critical instructions visible and test error messages on the device. Photographs, signatures and audio increase storage and personal-data risk, so they need a purpose, size limit, naming scheme and access rules.
Prepare data and cartography for the device
Assign UUIDs to objects that different teams can create or relate. Do not rely on local sequences that can collide. Define CRS, editable layers, reference layers and a basemap limited to the work area. Test size, opening time, battery use and behaviour at the expected scale.
Package only what the operation needs. An oversized basemap can make the project unusable; one that is too general can lead to incorrect capture. Preserve the phone's reported location accuracy as metadata rather than describing it as a topographic survey.
Rehearse departure, return and reconciliation
Before fieldwork, copy or download the package, enable flight mode and run valid and invalid cases. Then simulate device loss, duplicate records, simultaneous edits and a damaged attachment. Define who backs up, who synchronises and who decides a conflict. Avoid changing the schema while field edits are pending unless the impact has been assessed.
For asset inventories, this workflow can feed the utility network cadastre with traceable observations without treating mobile GPS as engineering geometry.
Measure a representative pilot
Test one area with straightforward logistics and one with difficult conditions. Measure complete records, conflicts, review time and recovery from backup. GeoSAT's offline field capture with QField can cover configuration and operations. It cannot guarantee that every record is correct: acceptance depends on protocol, training, equipment and agreed quality controls.
Acceptance check before field deployment
Create a lab project with three fictional points and a UUID for each record. Package the project, editable layers and a licensed basemap. On the phone, enable airplane mode, close the app, reopen it and complete an inspection with a photograph. Confirm that the form rejects invalid values and that the attachment stays inside the expected package.
Reconnect and synchronize using the selected cable, package or QFieldCloud workflow. Reopen the result in QGIS and compare identifier, geometry, fields and photo. Send the same package twice to detect duplication. A connected demonstration does not prove offline operation. Continue with conflicts and attachments.
Build a small field package before a full survey
Use the downloadable laboratory as a source of synthetic assets. It includes 10,000 points, but the first mobile rehearsal should use a selected subset of 20, exported to its own GeoPackage. Preserve asset_id; do not generate new asset identifiers when preparing another crew's copy. The downloadable project is a desktop starting point, not a claim of an executed QField device test.
Create a separate inspection table so repeat visits do not overwrite asset identity. For the rehearsal, use this proposed schema:
| Field | Purpose | Form behavior |
|---|---|---|
inspection_uuid | Unique identity of this visit | Generate once on creation; not editable |
asset_id | Link to the assigned asset | Relation to the selected asset table |
visited_at | Time of observation | Store with an agreed timezone convention |
condition | Structured observation | Value map: good, review, critical |
status | Workflow state | draft, complete, queried, accepted |
note | Reason or observation | Required when condition needs explanation |
photo_path | Relative attachment reference | Attachment widget |
This is a suggested practice model, not part of a legal inspection standard. Decide which fields the crew may change and which belong to an office reviewer. Merely hiding accepted in a form does not enforce approval permissions in a central system.
Configure identities, relations and forms
In QGIS, create the inspection table in the working GeoPackage. Match the asset_id type to the parent layer. Configure the UUID default as uuid('WithoutBraces') on a text field and do not apply that default again on update. Keep the GeoPackage's local integer feature key separate from the UUID used to reconcile visits across devices.
Create a project relation from inspection asset_id to asset asset_id. Open an asset and create two child inspections. Check that each receives a different UUID while both retain the correct parent. Close and reopen the project to verify persistence. A relation that displays correctly once but stores a different field is not ready for packaging.
Arrange the form in the order the crew performs the task: identify the asset, record condition, add evidence, review completeness. Put instructions next to the relevant field. Avoid making every field required; the crew needs a truthful way to record inaccessible assets, unsafe access or unavailable information. “Not observed” is different from a favorable condition.
A draft may remain incomplete, while a completed inspection requires a condition. For the schema above, a QGIS expression can express that rule:
"status" != 'complete' OR
("condition" IS NOT NULL AND trim("condition") != '')
Make status itself non-null and configure its allowed values separately. Test the constraint on the actual phone. A correct desktop expression is only one part of mobile form behavior. Review QField form configuration for supported widgets in the installed release.
Make photographs portable
Configure the attachment widget with a path relative to the project package. Capture a test image from inside QField, close the project and reopen it while offline. Copy the complete package to the return workstation and open the same attachment there. An absolute path pointing into one phone's storage is not a portable attachment reference.
Use filenames that avoid collision between devices and preserve the relationship to the inspection. UUID-based naming is useful; relying on a camera's IMG_0001 sequence is not. Test two photos with the same original filename, an accented note and a large image. Set a practical image-size policy based on the detail needed for review and the expected transfer conditions.
For multiple photos per visit, use a child attachment table rather than adding photo_1 through photo_20 fields indefinitely. Each attachment needs its own identifier, owning inspection UUID, relative path and useful metadata. The attachment documentation describes the widget boundary; your packaging and reconciliation procedure must still preserve the files.
Assign work to reduce conflicts
For the first pilot, give each crew an exclusive set of assets. Both crews can consult shared reference data, but only the assigned crew creates inspection changes for its work area. This operational division reduces conflicts without pretending the synchronization mechanism can resolve every business disagreement.
Keep repeat visits as separate observations. If two crews inspect the same asset intentionally, retain both inspection UUIDs and let a reviewer compare them. Do not replace the first observation solely because the second has a later timestamp. Device clocks, delayed uploads and different observation purposes can make “latest wins” inappropriate.
If the operation requires editing the same parent asset from multiple devices, add a deliberate conflict rehearsal before deployment. See the synchronization guide for the three-version comparison and return procedure.
Run an offline test that includes restarting
- Package the selected 20 assets, inspection table, form resources and permitted offline basemap using the chosen QFieldSync or QFieldCloud workflow.
- Download or copy everything while connected, then enable airplane mode and close the app completely.
- Reopen, locate three assigned assets and create inspections with photographs. Leave one as draft and complete another.
- Attempt an invalid completion and verify the message identifies the missing input.
- Restart the app again and confirm the records and photos remain usable without a connection.
- Return through the documented synchronization method and reconcile UUIDs, asset links, fields and files in QGIS.
- Attempt the same return twice and determine whether the workflow prevents or detects duplication.
Record the device model, operating system, QGIS, QField, QFieldSync and synchronization method. These are instructions for the organization's pilot; this article does not report a completed device benchmark.
Separate positioning quality from application choice
A mobile application's map location is not automatically survey-grade. Establish the required positional quality, receiver, correction method and acceptance procedure. Record accuracy metadata where useful and inspect whether it is available for each captured point. A good-looking symbol does not establish measured accuracy.
In difficult terrain or urban obstruction, define what the crew should do when the target quality cannot be reached. Preserve the observation with a review state when appropriate instead of encouraging a false precision claim. Test the actual receiver and device combination; compatibility and operating behavior cannot be inferred from another team's setup.
Name operational owners
| Responsibility | Owner to assign | Evidence before departure |
|---|---|---|
| Package preparation | GIS coordinator | Correct area, version and editable layers |
| Device readiness | Crew lead | Storage, battery, offline opening and camera |
| Return and backup | Data operator | Complete package preserved before reconciliation |
| Conflict decisions | Domain reviewer | Written rule and unresolved-case handling |
| Publication | Authorized editor | Accepted records only through intended path |
After the pilot, measure completed records, rejected records, missing attachments, duplicates, reconciliation minutes and recoverable work after a simulated device interruption. Use those observed values in the field-app comparison and the cost model. Downloading a free application does not establish that the operation is cheaper or more reliable.