Designing GIS field forms for GNSS surveys

Begin with the decisions the form supports

A field form should collect the information needed to identify an object, interpret its position and support the project’s next decision. Start with the users of the dataset rather than a long list of possible fields. A maintenance inventory, terrain survey and research plot record require different attributes. Define the purpose of each field and remove values that nobody will use or verify.

Agree a small set of essential information with the field and office teams. Include the physical observation point, feature type and stable identifier. Keep positioning metadata distinct from descriptive asset attributes. A form is successful when a crew can complete it consistently and a reviewer can understand the evidence later, not merely when every available box is filled.

Continue learning Exporting GNSS data to GIS without losing its meaning

Separate features from observations

A physical asset or plot may be visited many times. Give it a stable feature identifier and use a separate observation identifier for each visit or measurement. This supports history without duplicating the object. A new GNSS coordinate may improve an existing record rather than represent a new asset. The data model should make that distinction possible.

Record observation date, operator, method and review status with the visit. Link photographs and notes to the same observation or feature through an explicit key. Do not rely on file order or approximate time matching. Clear identity relationships reduce the risk that a correct coordinate is attached to the wrong asset or that a later update erases the original evidence.

Continue learning Designing a geodatabase schema for GNSS point observations

Use field types and units deliberately

Choose numeric, text, date and coded fields according to their meaning. Identifiers that contain leading zeros usually need text handling rather than arithmetic. Measurements should have defined units and physical references. A depth field is incomplete unless the crew knows whether it refers to a pipe crown, invert, centreline or another specified point.

Test the intended export format early. Long identifiers, special characters, dates and decimal values may behave differently across applications. Keep unit labels visible in the form and avoid mixing units within one field. A well-designed schema prevents many errors before fieldwork, whereas a generic notes column leaves the office team to reconstruct meaning after the site is no longer accessible.

Continue learning Mapping water network assets with GNSS and reliable field records

Validate what can be known in the field

Use required fields for information the crew can reasonably establish. Provide an unknown or not observed state with a reason where appropriate. Requiring a value for an inaccessible chamber or unreadable label can encourage guessing. Validation should improve evidence quality, not make the form appear complete at the expense of truthfulness.

Apply sensible range and relationship checks based on the project definitions. For example, an observation marked offset-derived should require the offset evidence fields. Avoid arbitrary numeric limits that have not been agreed for the task. Test unusual but legitimate cases so the form does not reject real observations or force them into an incorrect category.

Continue learning Recording drainage assets with GNSS and clear field evidence

Capture positioning provenance automatically where possible

Store the coordinate reference, method, correction status and relevant quality metadata provided by the supported equipment workflow. Keep these fields understandable and document their meaning. A receiver indicator is not a universal accuracy guarantee. The project’s acceptance assessment should consider observation conditions and independent checks in addition to automatically recorded values.

Allow the crew to note obstructions, soft ground, uncertain targets and alternative methods. If a position is derived from an offset, preserve the measured reference and derivation. Do not reduce every record to one coordinate and one generic quality label. The reviewer needs enough information to distinguish direct observations from derived or provisional positions.

Continue learning Exporting GNSS data to GIS without losing its meaning

Design for offline collection and recovery

Test the form without connectivity, including creation of identifiers, photographs and edits. Confirm that records remain linked when synchronisation resumes. Define how conflicts are handled if two crews update the same feature. A workflow that works only during a stable office connection may fail in exactly the field conditions where reliable local storage matters most.

Keep a practical recovery process for interrupted sessions or device replacement. Use supported backup and synchronisation methods rather than manual copying that may break database relationships. Train crews to recognise unsynchronised records and confirm successful transfer. The goal is to preserve the evidence chain from field observation to reviewed dataset even when a network connection disappears.

Continue learning Designing a geodatabase schema for GNSS point observations

Pilot the complete capture-to-office workflow

Collect a small representative sample before production. Include a normal feature, an unknown value, an offset observation, multiple photographs and a revisit. Export the sample and load it into the receiving GIS or asset system. Review it with the people who will process and use the data, not only the person who built the form.

Check identifiers, units, dates, coded values and attachment links. Ask whether a reviewer can reconstruct what the crew observed without additional explanation. Revise the form based on actual confusion. A pilot often reveals terminology or workflow problems that a technically valid schema cannot detect, and correcting them early is far cheaper than repairing thousands of inconsistent records.

Continue learning Mapping water network assets with GNSS and reliable field records

Maintain the form as a controlled project asset

Assign a version to the form and its data dictionary. Record changes to fields, codes and validation rules, including the date they take effect. Keep old records interpretable when the schema evolves. Quietly changing a code’s meaning can make historical data misleading even if every database row remains technically valid.

Deliver the form definition, schema, capture guidance and review process with the dataset. Preserve unresolved issues and the evidence behind corrections. A dependable GNSS field form connects the physical object, observation method and descriptive record in a way another person can understand. Its value comes from consistent meaning and traceability, not from the number of fields or the visual polish of the interface.

Continue learning Recording drainage assets with GNSS and clear field evidence

Test an unknown asset case

Suppose the crew finds a cover at the expected location but its label is missing and the owner cannot yet confirm its identity. The form should allow a new observation with a provisional feature relationship, photographs and an unresolved status. It should not force the crew to select a nearby database record simply because that is the only way to save the point.

The office reviewer can compare the evidence with owner records and resolve the identity later. Preserve the provisional identifier and cross-reference any approved merge. This protects the original observation while allowing the inventory to improve. Testing this case during the pilot reveals whether the form supports honest uncertainty or merely encourages complete-looking records that hide unsupported assumptions.

Include a review field that distinguishes an unresolved identity from a missing observation. The crew did observe something, and that evidence should not be discarded simply because the asset match remains open. A reviewer can later resolve the relationship while preserving the date, position and photographs from the visit. Test whether the receiving system can represent this state. If it cannot, agree a companion issue table rather than forcing the field form to convert uncertainty into a false asset match merely to satisfy an import requirement.

Continue learning Exporting GNSS data to GIS without losing its meaning