Building a GNSS field coding dictionary that survives export
Define feature codes and attributes before production so survey observations become consistent, useful GIS or CAD data.
Start from the final dataset
A field coding dictionary connects an observed point to its meaning. It tells the crew how to classify a feature and which attributes to record. Begin with the client dataset or design workflow, not with a list of abbreviations chosen only because they are quick to type. Identify the features, required fields and export conventions that the final system expects, then work backward to a practical field form.
Separate coordinate quality from feature meaning. A precisely measured point with an ambiguous code may still be unusable for asset management. Conversely, a detailed asset description does not prove that its coordinate meets the project criteria. The dictionary should help preserve both kinds of information: what the feature is and the observation context needed to interpret its location. Do not hide one inside an improvised free text note intended for the other.
Continue learning Exporting GNSS data to GIS without losing its meaning
Define codes unambiguously
Use a controlled code for each intended feature class and provide a plain language definition. Explain close distinctions such as the centre of a cover versus the edge of its frame, or a channel bank versus its invert. The operator needs to know what physical point to occupy, not merely which acronym to select. Include a sketch or example photograph for features that are easily confused in the field.
Keep the vocabulary manageable. A dictionary with many nearly identical codes can slow the crew and increase inconsistent choices. Where the distinction belongs in an attribute, use a stable feature code with a controlled attribute value instead. Avoid changing code meanings during production. If a definition must change, issue a new version and identify which sessions used the earlier interpretation so the office can reconcile the records deliberately.
Continue learning GNSS road corridor surveys: building a consistent route dataset
Design useful attributes
Specify the required attributes, allowed values and units. A pipe diameter field should not mix an unlabelled number with a narrative description. A condition field should have agreed categories where the client needs comparison across assets. Include an explicit unknown or not observed state when appropriate, so the crew is not forced to invent a value merely to satisfy a mandatory field.
Distinguish direct observations from information obtained from drawings, labels or another person. A field inspector may see an asset cover but not the buried structure beneath it. The dictionary should make that uncertainty visible rather than encouraging an unsupported description. Use separate source or confidence fields where the workflow needs them. This preserves the difference between what was measured, what was observed and what was inferred.
Continue learning Handing GNSS survey coordinates to CAD teams without losing meaning
Test controller behaviour
Build the dictionary in the actual field application and test it with representative records. Check required fields, dropdown values, text lengths and special characters. Confirm that operators can correct an entry without losing the coordinate or creating an unexplained duplicate. A well designed spreadsheet schema can behave differently when converted into a controller form, so the device test is an essential part of the design.
Include linework or feature connectivity tests if those functions are used. Confirm how start, continuation and end actions appear in the export. A missing sequence marker can produce a line joining unrelated points even though every individual coordinate is valid. Preserve a small known test dataset so a future dictionary or software revision can be checked against the same expected interpretation before it reaches production.
Continue learning A QGIS workflow for reviewing GNSS survey data
Verify the export and import
Export the test records through the intended route and open them in the destination GIS or CAD software. Check codes, attribute names, units, character encoding and null values. Make sure a field truncated by one program does not silently merge two different meanings. If the destination expects a particular geometry type, verify that the export creates that type rather than assuming feature codes automatically build the correct object.
Keep coordinate reference information alongside the attributes. For GeoJSON delivery, follow the applicable format requirements and transform coordinates appropriately rather than copying projected grid values into longitude and latitude fields. Test the location against known data in the destination system. A successful file import only proves that the syntax was accepted; it does not prove that the feature meaning or coordinate interpretation survived the transfer.
Continue learning Exporting GNSS data to GIS without losing its meaning
Train through real examples
Review the dictionary with the crew using a small set of actual site features. Ask operators to explain which point they would occupy and how they would record an uncertain attribute. Differences in interpretation are useful feedback before production. Update definitions and examples where necessary, then issue the approved version. Training should connect the code to a physical feature, not merely to a memorized keyboard shortcut.
Provide a quick reference for uncommon codes and a controlled way to request additions. An improvised new abbreviation should be flagged for review rather than silently accepted as a new standard. Keep free text notes available for exceptional context, but do not rely on them to repair every missing definition later. Consistency is easier to create at collection time than to infer from hundreds of short, contradictory notes.
Continue learning GNSS road corridor surveys: building a consistent route dataset
Manage the dictionary as project data
Store the dictionary version with each job and preserve the source used to create it. Record approved changes, including renamed fields and altered allowed values. If several crews work simultaneously, confirm that they all have the same active version. A shared code name is not enough if one controller uses an older definition or omits an attribute that another crew considers mandatory.
Review a sample of early production records while the crew can still revisit the site. Look for missing values, unexpected codes and inconsistent physical point choices. Use that review to correct the workflow promptly. A successful dictionary makes the survey easier to understand after export, reduces office interpretation and preserves the connection between a coordinate and the real feature that the client expects it to represent.
Continue learning Handing GNSS survey coordinates to CAD teams without losing meaning
A code definition for a drainage feature
For a drainage asset, a code labelled simply drain may be too vague. The project may need separate definitions for a cover centre, an accessible invert and a channel edge because they represent different physical points and support different analysis. Define which locations are to be occupied and which dimensions or observations belong in attributes. Include an unknown state when a required feature cannot be observed from the approved field access.
Test the resulting records in the destination GIS or CAD workflow. Confirm that points and lines connect as intended and that an unobserved invert is not converted into a zero height or another misleading value. This example illustrates how a dictionary protects meaning rather than merely speeding data entry. The crew should not have to invent an interpretation at each asset, and the office should not have to guess which physical part of a feature a precise coordinate was meant to describe.
Continue learning A QGIS workflow for reviewing GNSS survey data
Practical checklist
- Define the physical point associated with each code.
- Test attributes and connectivity on the actual controller.
- Verify the complete export in the destination software.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
