A utility map can put a pole on the correct side of the road and still leave a designer unable to use it. The missing piece may be an attachment height, an unreadable tag, or a photo filed against the neighboring structure. We scope collection around the decisions those records must support.
This guide follows the work from the owner's data model through field checks to the receiving GIS. It covers existing utility and telecom networks, where measured observations often arrive beside older records with uncertain origins. We keep those sources distinguishable so engineering can use each one appropriately.
What GIS data collection must deliver
GIS data collection turns field observations into geographically referenced asset records that an owner can query and maintain. For utility and telecom networks, we preserve 2 distinct kinds of evidence: where an asset was measured and what was observed there. Usable records also retain their source and verification status.
Start with the receiving system. Before a field form goes into use, we ask the owner to identify the layer that will receive each asset type and the business purpose that makes its attributes necessary. An inventory for locating structures needs different evidence from a survey intended to support detailed design. Set the acceptance criteria first.
Separate the asset from its observations
A pole's identity should survive a new inspection. Its observations can change. We recommend a persistent asset identifier, with repeat visits recorded separately when the owner's model supports inspection history, so replacing a damaged tag does not silently create another pole in the database. Existing owner IDs belong in their own field when a collection system also generates an internal key.
A field form needs explicit answers for uncertainty. An unreadable ownership plate should produce an unresolved owner value and an explanation, rather than a guess based on which company appears on nearby equipment. Unknown is useful information. We distinguish unknown from not inspected because the first records an inconclusive observation while the second records work that has not been performed.
Make the schema a field agreement
Attribute standards begin with definitions. A field called height needs a reference point and a unit; a condition code needs an agreed meaning. We specify allowed values with coded domains and use range checks where measurements have meaningful bounds. The form should reject an impossible entry without forcing a technician to invent a plausible value just to save the record.
Relationships need the same attention as attributes. A support structure can carry multiple attachments, and each attachment may have a different owner or verification status. Store those observations as related records when the target model permits it, instead of joining everything into a comment that nobody can reliably filter. This also lets a replacement attachment retain the history of the structure supporting it.
We test the proposed form against representative conditions before extending collection across a route. Include an asset that is easy to identify and an asset that cannot be fully observed; the second often reveals whether mandatory fields allow an honest response. A desk review alone misses that problem. Our CAD/GIS documentation standards guide explains how common definitions support later drawing and record handoffs.
Test the actual handoff. Save a sample observation with its photograph, export it through the intended delivery method, and open it in the owner's GIS. Check the relationship there before approving the field form.
Field records for poles, structures and routes
The capture specification should tell a technician what observation is needed at each asset. It should also state the physical reference used for the coordinate, because a pole center and a point beside its base describe different locations. We carry that distinction into the record whenever direct occupation is impractical. The offset must remain visible.
The table maps the principal field records to their receiving checks. Each row needs an explicit disposition when access or visibility prevents collection. A blank cell cannot tell an owner whether the technician missed the feature or could not safely observe it.
Access requirements belong in the capture instructions. We define which observations can be made from the permitted working position and which require separate authorization, so a technician facing a locked structure has a valid way to document the restriction without guessing what lies inside. That exception should name the affected attribute. The office can then decide whether the missing observation blocks design or remains an acceptable inventory gap.
| Record | Field capture | Acceptance check |
|---|---|---|
| Pole | Tag, position and observed characteristics | Identity matches the correct structure |
| Attachment | Observed occupant and measured height reference | Related to the correct pole |
| Structure | Surface location and accessible details | Observed extent stays separate from inferred extent |
| Route | Alignment evidence and endpoint identifiers | Geometry reflects its stated source |
| Photograph | Asset association and view description | Image opens from the correct feature |
Poles and attachments
Capture identity before interpreting use. Pole tags and markings help reconcile a field observation with the owner's register, but a missing tag does not justify borrowing a nearby pole number. We preserve the observed marking and its photograph, then flag conflicts for reconciliation. A field-assigned identifier must remain distinguishable from an owner-confirmed identifier.
Attachment collection needs enough context for its intended engineering task. Record the observed attachment position and the measurement method, with a clear reference for any height value. A coordinate at the pole base says nothing about conductor clearance. Our pole data collection work connects the field record to the evidence engineering needs, while uncertain occupants remain unresolved until they can be verified.
Attachment height and pole condition also answer different questions. We keep the condition observation separate from any engineering determination of remaining capacity, because a visual field record cannot substitute for the inputs and analysis needed to evaluate a proposed loading change. The distinction affects acceptance: a complete inventory can still require additional measurements before engineering can reach a design conclusion.
Ground structures and route geometry
A handhole lid provides a visible surface reference. It does not reveal the complete underground installation. We distinguish a measured lid position from a chamber footprint obtained through authorized inspection, and we identify any route segment taken from existing records. A line drawn between access structures must retain that source description when the intervening alignment has not been observed.
Routes also need a clear lifecycle state. Proposed geometry and installed geometry can coexist in an owner's GIS, but the collector must not promote a planned alignment into an as-built record simply because it follows a plausible corridor. We preserve endpoint associations and record the evidence behind changes. A moved structure can otherwise leave a route visually connected to the wrong asset.
Photos that answer a field question
Photographs should explain a specific observation. An overall view establishes which structure was visited, while a detail view can support a tag transcription or show the feature behind a condition assessment. We associate images with the asset record at capture and verify that association during review. Camera coordinates alone are insufficient. They locate the photographer, who may be standing away from the asset.
Our photo review checks legibility before the field record is accepted. A sharp image of the wrong side of a pole cannot resolve an unreadable ownership plate, and an image attached to the wrong structure can make a mistaken record look convincing. The reviewer should be able to move from the attribute to its supporting image without searching a separate folder by filename.
Choose GPS accuracy for the decision
Accuracy belongs in the collection specification as an acceptance requirement, not merely as the name of a receiver. We separate horizontal position from elevation and ask how either will be used. GPS is one satellite system within GNSS; the quality of a stored coordinate also depends on the observation conditions and the processing method.
Meter, submeter and centimeter classes
Meter-level positioning can support reconnaissance and broad inventory where the owner accepts that tolerance and nearby features remain distinguishable. It should not be carried into a detailed design as if its coordinates were verified to a tighter requirement. Keep its purpose explicit. A point that is adequate for finding a structure can be inadequate for resolving its relationship to a narrow corridor.
Submeter positioning describes an accuracy requirement below 1 meter, with the confidence basis still needing definition. It can support asset mapping where the owner's specification accepts it, but dense groups of structures may require tighter positioning or stronger identification evidence. We do not choose an accuracy class from the map's zoom level. Display scale cannot improve the source measurement.
Centimeter-level positioning requires a collection method capable of meeting the specified tolerance under the actual site conditions. Corrected GNSS can support that work, but blocked satellite visibility or reflected signals can degrade the result even when the equipment is capable of better performance elsewhere. Check independent control. Repeated readings that agree with each other can still share a systematic error.
Position metadata should remain attached to the observation it describes. We preserve the receiver's reported quality and fix information where available, and document an offset method when the antenna cannot occupy the defined asset reference point. Changing the antenna height or applying an offset without recording it can leave a coordinate that passes a numeric threshold but represents the wrong point.
When survey-grade evidence matters
We require survey-grade methods when the intended decision depends on tight relative positions or reliable elevations, such as fitting a structure to constrained design geometry. The requirement must identify the reference system and verification procedure. Where the scope calls for a regulated survey deliverable, establish the responsible qualified professional and required certification before collection; equipment ownership does not establish that authority.
The National Geodetic Survey's GEOID18 Technical Details explains the distinction between GNSS ellipsoid heights and orthometric heights derived using a compatible geoid model. That distinction matters whenever a design uses elevations. We preserve the vertical reference and units instead of labeling every receiver altitude as a finished engineering elevation. The owner's specified datum controls the delivery.
Esri's ArcGIS Field Maps documentation, Prepare for high-accuracy data collection, explains that its 95 percent confidence setting governs collection acceptance while stored accuracy values remain RMS estimates. We therefore check what an accuracy field means before comparing it with an owner's tolerance. Record the confidence convention. A precise-looking decimal without that context can invite a false acceptance decision.
A limitation of our preferred structured field workflow is that a form can enforce completeness while still accepting an observation made on the wrong asset. Receiver metadata cannot catch every identity error. We retain photo and tag checks beside the positional checks, rather than treating successful submission as evidence that the record is correct.
Field QA for GIS data collection
Field QA works best while a technician can still resolve an ambiguity at the structure. We check the saved record against the physical feature and confirm that the photographs open before moving on. Correct it at the source. Office staff should not have to infer which pole a comment describes from a sequence of similar pictures.
Review exceptions without erasing them
Failed observations need a disposition. If a position falls outside the collection requirement, the field team can reobserve it under suitable conditions or use an approved alternative method. When neither is available, preserve the observation as an exception with its reason. We keep it out of the accepted measurement set until the responsible reviewer determines how it can be used.
Keep the original observation. If a reviewer moves a point to match an image or another layer, retain the original coordinate and record the edit's basis. The adjusted location must not keep a measurement-quality label that no longer describes it.
Offline collection introduces a separate custody check. A record visible on a tablet may still be absent from the shared dataset, so we verify synchronization and attachment transfer before considering that device's work delivered. Confirm the photos too. A feature count can match while image uploads remain incomplete, leaving the office with attributes it cannot corroborate.
Compare attributes with geometry
Office QA should look for contradictions that a field form cannot detect alone. Duplicate owner IDs deserve investigation, and a route endpoint associated with a distant structure needs an explanation. We distinguish legitimate exceptions from errors rather than deleting every flagged record. The reviewer records the resolution so the next import does not recreate the same problem.
Coordinate transformations need a controlled test before bulk processing. We compare known locations in the source and destination systems, confirm units, and examine whether the chosen transformation matches the source datum. For teams dealing with mismatched field layers and owner schemas, our GIS mapping services for utility records address that handoff within the engineering workflow.
Load and validate the owner's GIS
A successful import proves that the software accepted the data format. Operational acceptance needs more. We load into a staging area where the owner can inspect records without replacing the authoritative network, and we reconcile the results against the submitted package before any approved promotion. The loading method must match the owner's permissions and change-control process.
Preserve identifiers and relationships
Map fields explicitly. An import should define how source values become target values and how rejected records are reported. We test coded domains and identifier lengths, then check that attachment relationships survived the transfer. A shortened asset ID can look harmless in a table while breaking the connection between a pole and its inspection history.
Existing records require an update rule. Match on a stable owner-approved identifier wherever possible, and route ambiguous matches for review instead of merging features solely because their coordinates are close. Keep deletions separately controlled. Our guide to GIS data conversion for telecom networks covers the wider migration problem when new field observations must be reconciled with inherited records.
Concurrent edits need an agreed conflict rule. When an owner updates an asset after the field extract was prepared, we compare the incoming observation with the newer record before allowing either source to overwrite the other. The collection date helps explain the difference. The reviewer still needs to decide whether the change represents a corrected attribute or a physical alteration.
Test the record as an owner would use it
Acceptance should include a practical retrieval check. Open a sampled asset from the receiving map and follow its related observations to the images, then confirm that the displayed values agree with the delivered record. For a network model, test the required connectivity behavior against known relationships. A line touching another line on screen does not by itself prove a modeled connection.
We deliver unresolved exceptions with their affected asset IDs so the owner can restrict their use without discarding valid observations elsewhere. The accepted package should identify its schema version and collection period, with a clear record of subsequent edits. Retain the source package. That gives future maintainers a basis for distinguishing a field change from a transformation or import error.
Choose the collection scope before mobilizing
Utility asset managers: approve the identity rules and receiving schema before expanding an inventory. Prioritize reliable joins to existing records, because a newly measured point that cannot be reconciled with the register creates maintenance work instead of resolving it.
Telecom design leads: specify the measurements that determine your design decisions and separate them from general inventory attributes. Require tighter positioning where corridor geometry demands it, and leave unverified attachment details visibly unresolved until engineering has adequate evidence.
GIS administrators: prove the import with representative records before accepting a production delivery. Test updates against existing assets and retain a rejected-record report; otherwise an apparently complete transfer can conceal skipped features or broken photo relationships.
Draftech International delivers turnkey telecom and power infrastructure with 100% in-house engineering and full turnkey construction by Draftech-managed subcontract crews under Draftech's QA/QC. Our partner and delivery team connects field evidence to engineering decisions through as-builts and closeout. Bring the receiving schema and unresolved collection questions to our project contact team so we can define the handoff around the owner's requirements.
For an eligible route, the Draftech free-design offer provides engineering for the first 20,000 linear feet at no cost, from feasibility and field survey through permit approval. Each route request goes through owner review before Draftech commits its engineering package.
