Specify the height reference as well as the unit before accepting an elevation handover. Two files can both report metres while using different vertical references. For a UG73 survey inquiry, ask the receiving survey professional to name the required reference, identify the source reference and define the evidence needed for any transformation. Do not assume that an aircraft, a positioning label or an export filename resolves those questions.

A project manager receives a new elevation file and an older site dataset. Both contain a height column marked in metres, so combining them appears straightforward. Yet the person responsible for the survey has not approved their reference statements. This hypothetical situation is not evidence of a product defect. It is a reminder that a familiar unit describes only part of what a number means.

Keep the reference statement with the values

A useful brief should ask what each height represents, how its reference is identified and where that information will be recorded. The answer should travel with the data rather than remain in an email that the eventual recipient may never see. If the team cannot locate that answer, make clarification a delivery task instead of asking an analyst to fill the gap by assumption.

The buyer's role is not to improvise a transformation. It is to make sure that a qualified person owns the requirement and that the supplier understands what evidence is expected. Ask that reviewer to provide the terminology appropriate to the project. A vague request for corrected heights invites different interpretations; a reviewed source-to-destination statement gives everyone a concrete question to answer.

Natural Resources Canada's explanation of the Canadian Spatial Reference System distinguishes ellipsoidal heights from orthometric heights and describes their relationship through a geoid model, expressed as H = h - N. It also explains that CGVD2013 and CGVD28 are different height reference systems despite both relating heights to mean sea level. This background illustrates why a unit alone is insufficient. It does not provide a project-specific conversion or validate a UG73 survey result.

Describe the destination before commissioning the source

Begin with the dataset or decision that will receive the new information. Ask the owner of an existing elevation layer for its reference statement and for any limitations they already know. Ask what comparison or combination is intended. A deliverable used for a visual review may require a different acceptance discussion from one being incorporated into a professional survey workflow.

Do not simplify the requirement to the recipient's country. A Canadian project may contain legacy files, while a US project may receive information from several organizations. The country name is useful context, not a replacement for a dataset-specific statement. The relevant professional should determine which reference applies and which evidence is needed for the actual use.

For teams working across the United States and Canada, put responsibility for the handover in the project brief. Name the recipient, the owner of the source data and the person authorized to approve the reference treatment. Avoid assuming that familiar language on both sides of a border means the files are already compatible. This is an editorial documentation recommendation, not a statement of a universal cross-border surveying rule.

Give every transformation a traceable question

If a transformation is proposed, ask the responsible specialist to explain its purpose before asking for the finished export. What is being transformed, from which reference to which destination, using which identified method or resource? Which parts of the project remain outside that operation? The explanation should be understandable enough for the project manager to record without pretending to replace the specialist's judgment.

Keep the received source file and the delivered result identifiable as separate records. The buyer should be able to follow the relationship between them and locate the processing explanation. This is a proposed evidence-management practice, not a promise that keeping more files makes the survey accurate. Its value is that a later reviewer can inspect what was done instead of guessing from a renamed file.

Agree how unknown information will be reported. If the source reference cannot be established, an explicit unresolved status is more useful than a confident-looking output with an undocumented assumption. A schedule may need to change while evidence is obtained. That is a project decision for the responsible people, not a reason to label an unsupported result as verified.

Request a sample handover that the recipient can review

Before a large production delivery, propose a small representative sample with its reference statement and processing explanation. Have the receiving survey professional decide what should be checked. The purpose is to test whether the proposed package communicates the required information and fits the receiving workflow. It is not an invitation to extrapolate a small review into a blanket accuracy guarantee.

Ask the recipient to record the outcome in terms that distinguish a documentation issue from a technical finding. Missing metadata, an unclear reference description and an observed disagreement are different matters. Each may require a different next step. Keeping them separate helps the project manager request the right evidence without turning every question into an argument about the aircraft.

For example, a hypothetical sample may arrive with an adequate source statement but an unclear destination label. The immediate action is to clarify the intended destination and obtain the responsible review. It is not to adjust values until they look closer to a previous map. The example is a decision habit, not a numerical conversion procedure.

The field lesson is about approval timing

Have the receiving professional approve the reference statement before the file is merged into an existing layer. That is the practical lesson we recommend. It moves a necessary conversation earlier, when questions can still be tied to the original package. Waiting until after several downstream products have been made can leave multiple teams unsure which version they used.

Make this review a named handover item. The person accepting the reference documentation does not automatically accept every other aspect of the survey. Record the limits of the approval and route additional questions to their owners. A short, bounded sign-off is clearer than an all-purpose approval phrase whose meaning expands each time it is forwarded.

What to ask about UG73

The UG73 survey-oriented fixed-wing VTOL drone product page provides the starting point for a configuration inquiry. It does not by itself establish the reference system of a finished deliverable, the inclusion of a particular sensor or processing service, or the acceptance of a survey by its recipient. Ask UNITED UAV which configuration details are available and which questions require the proposed survey or integration provider.

Keep unknown facts unknown. Do not infer a complete positioning and processing chain from an image, model name or broad application description. Ask for configuration details and supporting documentation for the proposed system. Then let the appropriate professional evaluate whether that evidence addresses the intended project. An inquiry can be commercially useful without claiming a capability that has not been confirmed.

When comparing the VTOL and fixed-wing drone collection, retain the same receiving requirements across the shortlist. That makes aircraft discussions more consistent. It also reveals when two proposals cover different scopes, such as aircraft supply alone versus a wider service package, without treating either scope as an automatic quality verdict.

Related questions that deserve their own checks

A compact receiving record can include the source file identifier, the supplier's reference statement, the requested destination, the reviewer's decision and any remaining limitation. It should distinguish information supplied by the provider from information confirmed by the recipient. That distinction matters when a project manager prepares a summary for someone who has not read the complete technical record.

What happens when an older dataset has incomplete documentation? Ask its owner and the responsible survey professional what evidence can be recovered and what use, if any, is appropriate while the uncertainty remains. Do not select a reference because it produces a visually pleasing match. An unresolved legacy file can be listed as a project dependency without forcing the new acquisition into an undocumented assumption.

Likewise, changing a label is not the same as demonstrating that values have been treated correctly. Ask the reviewer to identify the evidence supporting the delivered reference statement. The acceptance record should describe an actual review, not merely repeat the desired wording from the purchase brief.

The meaning of a height is not the only interpretation issue in a mapping package. Our UG32 raster-resampling guide discusses category codes and processing choices. Our UVH-RTF guide to true and magnetic north addresses reference language in a desk-based learning exercise. These are separate subjects, but each starts by asking what a value or label actually represents.

• Name the receiving dataset and its responsible reviewer.
• Attach the reviewed destination reference and unit requirements.
• Ask how the source reference will be documented.
• Identify who will assess any transformation and its limitations.
• Agree what evidence and sample package will support acceptance.

To move the discussion forward, contact UNITED UAV about the UG73 configuration and include the receiving reference statement, project location and intended deliverable. Mark unresolved survey questions clearly. This creates a precise starting point for the supplier and the survey professional while avoiding an unsupported promise that a particular aircraft choice makes two elevation files interchangeable.