UG21 Contour Deliverables: Ask What Smoothing Changed Before Using the Lines
Before using smoothed contour lines from a proposed UG21 survey workflow, ask for the unsmoothed source, the processing record and a statement of permitted use. A more flowing line is a cartographic result, not additional evidence about the terrain. Approval should depend on what the team will do with that derivative, not simply whether it looks better on a presentation map.
The attractive map can hide the important question
Imagine a project review in which two versions of a hillside arrive together. One has angular contours and the other has elegant curves. The presentation team prefers the second. The engineering reviewer asks whether the lines moved, and nobody in the room has the processing notes. This is a hypothetical buying problem, not a reported UG21 project. It illustrates why a request for a polished map needs a separate conversation from a request for data that someone will measure, compare or reuse.
A buyer can resolve that conversation before commissioning a large survey. Put the intended uses beside the deliverable names. A line layer for a slide deck may have a different review path from a layer supplied to a designer. Neither purpose should remain implicit. The contractor should know which version is being accepted for which purpose, while the recipient should be able to identify that version without relying on a conversation that happened weeks earlier.
What the software documentation establishes
Esri describes its Smooth Line tool as a cartographic operation. Its PAEK option can produce lines that do not pass through the original vertices, while barrier features can constrain the result. That is evidence about a named software tool, not a statement about UG21 survey accuracy or a recommended tolerance. The procurement implication here is our analysis: ask what changed and retain the evidence needed to inspect the change.
Do not ask the supplier to promise that every smoothing method preserves every analytical property. Instead, identify the actual method proposed for the project and ask its responsible specialist to explain the consequences relevant to your use. A generic statement that the map was cleaned up is insufficient. Equally, a long software manual is not a substitute for a short, release-specific record that tells the reviewer what happened to the delivered layer.
Request a paired sample, not a second sales illustration
A useful sample starts with the same small area in both versions. Ask the provider to retain the same extent and identify the two datasets clearly. Include a tight bend, a relatively straight section and an area where the line approaches another feature important to the project. These are proposed review cases, not universal acceptance tests. The technical reviewer should choose the actual examples and decide whether they adequately represent the intended delivery.
Require the sample files as well as the screenshots when editable linework forms part of the proposed purchase. Screenshots can help a meeting move quickly, but they cannot answer every question about the underlying coordinates or attributes. Have the supplier identify how a line in the derivative relates to the source record. If that relationship was changed during processing, the handover should explain the replacement method rather than imply that record numbers alone prove continuity.
Build a short transformation record
The record does not need to become a second survey report. It needs enough detail for the recipient to distinguish the source, the operation and the result. Assign ownership before drafting the purchase order. A processing specialist can describe the operation, a technical reviewer can assess suitability, and the buyer can confirm that the promised evidence arrived. Those responsibilities should not be collapsed into one unsigned statement saying that the map is acceptable.
| Record item | Buyer question |
|---|---|
| Source identity | Which exact line layer and terrain source entered the operation? |
| Processing identity | Which method, software release and relevant settings were used? |
| Output identity | Which delivered file contains the reviewed derivative? |
| Review evidence | Who compared the sample, what was examined and what remained unresolved? |
| Use boundary | For which stated purpose was the derivative accepted? |
Keep an explicit answer for an omitted item. Unknown, not supplied and not applicable are different states. An empty cell leaves a later reviewer guessing whether the information was forgotten or deliberately excluded. Ask the supplier to explain material omissions before the sample becomes the template for the full delivery, particularly when different subcontractors are responsible for collection, processing and final map production.
Separate visual review from technical release
Consider a buyer who commissions a public-facing planning illustration and an editable technical dataset together. The communications reviewer may accept the map's legibility while the technical reviewer still has an open question about the derivative. A sensible acceptance sheet permits those decisions to be recorded separately. It does not force either reviewer to approve work outside their competence merely because both files arrived in the same delivery folder.
The release note should also identify what the reviewer did not examine. For example, a comparison of selected contour bends is not evidence that every terrain value has been independently validated. A successful import into a desktop application is not a complete fitness assessment. These boundaries make the evidence more useful, not less: the next person can see which decisions remain theirs instead of inheriting an apparently unlimited approval.

Deal with exceptions while the source is still available
If the paired sample raises a concern, record the location and the precise use that is affected. Avoid an instruction such as make all the lines smoother, which may solve the presentation complaint without resolving the analytical question. Ask the provider whether the issue concerns the source, the chosen operation, the output or simply the recipient's interpretation. The answer determines which specialist needs to respond and what evidence should accompany that response.
Retain the reviewed source while the exception is being resolved. A replacement output should receive its own identity and a note explaining what supersedes what. The buyer should not have to compare filenames informally to discover that a revision was issued. If only one area changes, ask whether the new release contains the entire layer or an agreed partial replacement, and make sure the receiving team understands the chosen handover.
A practical buyer lesson
As an editorial review exercise, have one reviewer trace a tight bend in the source and another trace it in the smoothed version before they discuss the result. Then bring the two views together with the processing record. The point is not to invent a numerical acceptance threshold. It is to expose whether both people are examining the same object and expecting the same function from it.
This desk-based exercise is particularly useful when the map author and the eventual recipient work in different organizations. It makes assumptions visible without requiring another flight or an unsupported change to aircraft settings. Record the disagreement in ordinary terms, identify the responsible technical owner and ask for a documented decision. This is a proposed procurement practice, not an account of personal field experience or a claim that a specific customer used it.
Keep the aircraft inquiry within its evidence
The UG21 4-Hour VTOL Fixed Wing Drone for Mapping, Inspection and Surveillance is an approved product identity in the current catalog. Its product name is not evidence that a particular contour-processing service, sensor, software license or acceptance result is included. Ask UNITED UAV to confirm the proposed configuration and separately identify who would supply and review the mapping deliverables. Do not transfer a general cartography example into a claim about the aircraft.
For buyers in the United States and Singapore, the immediate purchasing question is the same: can the recipient identify the source, understand the derivative and obtain a responsible answer about its intended use? This article does not state local survey requirements or flight permissions. Those need project-specific review. Keep procurement evidence, professional technical acceptance and lawful aircraft operation as separate responsibilities in the proposal.
Is the unsmoothed version automatically suitable?
No. Retaining a source allows comparison; it does not establish that the source meets the project's needs. Ask the responsible specialist to identify the evidence supporting each version and the limitations that remain. If neither version is suitable for the proposed use, the remedy is a revised scope and a documented technical decision, not a preference for whichever file appears more original.
Connect this decision to the rest of the delivery
Line smoothing is only one example of a derivative that can look more polished than its source. The same distinction between presentation and analysis appears in mosaic color-balancing reviews. A different counting issue arises when a point-cloud proposal uses an undefined density figure; see the pulse-versus-return density checklist. These related questions should support one coherent deliverable brief, not create unrelated acceptance paperwork.
Before requesting a quote, write down the intended contour use, the file formats your team needs, who will make the technical decision and one representative area for review. Browse the VTOL and fixed-wing drone collection for the available product range, then send your contour-delivery requirements. Ask for configuration details and a paired source-versus-smoothed sample as separately identified parts of the proposed scope. A clear answer about the linework is more valuable than an attractive map with an unexplained processing history.