When a survey handover connected with a proposed UG32 workflow says feet, ask which definition it means. The international foot and the legacy U.S. survey foot are different units. Identify the source definition and the required output reference system before combining coordinates or quantities. Preserve the original records and assign any conversion to the responsible survey or geospatial specialist. Renaming a unit field is not evidence that a reviewed conversion occurred.

A familiar label can leave an important question unanswered

A file can look thoroughly documented while its unit label remains ambiguous. A receiving team may recognize the word feet and proceed directly to comparing coordinates. An older project may have used a specific definition that is no longer the default for new work. The problem is not solved by assuming that the author intended the receiver's preferred convention.

In a fictional procurement review, imagine a new survey output arriving beside an archived engineering file. Both show familiar coordinate fields and both are described in feet. Before investigating an apparent offset, the reviewer needs to establish the units and reference systems of both files. This example is a decision exercise, not a claim about an actual UG32 mission or customer.

The buyer's role is to make the evidence available and assign the review. It is not to choose a conversion factor from memory and edit production records during a meeting. A small ambiguity in the scope can create a larger disagreement over which organization is responsible for reconciling the files.

The current U.S. reference point

NIST's U.S. Survey Foot guidance identifies the international foot as exactly 0.3048 meter and the U.S. survey foot as exactly 1200/3937 meter. NIST states that, beginning January 1, 2023, the U.S. survey foot should be avoided except for historical and legacy applications. The guidance does not mean that archived coordinates can safely be relabeled without examining their original definition.

For procurement, the practical distinction is between a current output requirement and the truthful description of an existing input. A project may need to preserve a legacy file as received while producing a separately reviewed current deliverable. The appropriate treatment depends on the project reference system and the responsible professionals' requirements. This article does not replace their survey instructions or a jurisdiction-specific specification.

Inventory the incoming evidence

Ask the data provider for the original coordinate-system declaration, unit definition and any accompanying documentation. Retain the file name, source organization and relevant revision information. If a unit is expressed through a coordinate reference system rather than a plain text field, have the specialist interpret that declaration instead of guessing from a spreadsheet heading.

Separate confirmed information from assumptions. A note that a file was probably created in a particular software environment is not the same as a verified unit declaration. If the source owner cannot establish the definition, record the uncertainty and its effect on the receiving task. An unresolved assumption should remain visible in the acceptance decision.

Also identify which fields actually represent lengths or coordinates. A record may contain identifiers, dates, counts and descriptive labels alongside measurements. A broad spreadsheet conversion can damage unrelated fields. The required transformation should be defined by the data structure and the intended use, not by the appearance of a numeric column.

Distinguish a unit change from the whole coordinate operation

A coordinate reference system contains more information than a length unit. Establishing the foot definition is therefore one part of the review, not a universal explanation for every mismatch. The responsible specialist should identify whether the task involves only units or also other reference-system differences. Do not prescribe a single multiplication as a complete remedy without that assessment.

Ask for a short operation description that names the input, output and assumptions. The explanation should be understandable to the project manager while retaining enough technical detail for a geospatial reviewer. A statement that the file was fixed does not reveal whether the values changed, the declaration changed, or both.

The companion point-cloud CRS assignment and reprojection review addresses that distinction directly. Declaring what coordinates mean and transforming them are separate actions. Unit clarification helps establish the input truth needed for such work, but it does not establish that a particular transformation has been performed correctly.

Agree an acceptance sample before full delivery

Choose a small authorized sample that represents the legacy input and the intended receiving workflow. Ask the specialist to document the source definition, proposed operation and expected output interpretation. The sample should be selected for its usefulness in testing the handover, not because it produces an attractive map.

Retain a before-and-after record for the reviewed fields. The reviewer should be able to trace the output to the original input without relying on an undocumented workstation state. Where an external reference is needed, record what it is and why it is appropriate. Do not infer correctness solely because two layers appear close at one display scale.

Have the receiving team perform its actual task on the sample. That might involve importing a file, comparing a specified feature or preparing a quantity review. Record which part of the task succeeded and which questions remain. The outcome is evidence about the agreed sample and process, not a blanket guarantee for every historical dataset.

Keep originals and exceptions visible

Preserving an untouched input is a straightforward way to keep the review auditable. Store the converted deliverable separately and identify the relationship between the two. A corrected label in a working copy should not erase the original declaration or the reason it was questioned. This is particularly important when several organizations exchange files over time.

An exception register can be brief. For each unresolved file, identify the missing declaration, the source contact, the person assigned to investigate and the task affected. State whether the file is excluded from a particular comparison until the question is resolved. Avoid a generic warning that is detached from the actual data it concerns.

If a later answer changes the interpretation, document the new evidence and the resulting revision. The fact that a team has used a file for a long time does not prove its current interpretation is correct. Equally, a newly discovered label difference should not trigger destructive changes before the specialist evaluates its significance.

Put responsibility into the commercial scope

The aircraft supplier, collection contractor, processing provider and engineering reviewer may be different parties. Ask who is responsible for identifying legacy units and who approves the resulting conversion. If no one owns the task, the project can reach delivery with a technically important question that has never been priced or scheduled.

Request a quotation that separates data acquisition from reconciliation of third-party records. The latter may require information the provider does not control. A reasonable scope names the input assumptions, the evidence the buyer must supply and the circumstances that would require a revised estimate. It should not imply unlimited repair of undocumented archives.

Review exclusions with the same attention as deliverables. If the supplier will provide new data in an agreed reference system but will not validate legacy files, make that boundary explicit. The buyer can then arrange the missing review before depending on a combined result.

Coordinate units are only one preservation check

After the unit definition is established, other reporting properties still need attention. A correctly labeled quantity can still be misunderstood if the calculation behind it is unclear. The related thermal region and statistic review examines that reporting distinction in another measurement context. Use each check for the specific claim it can actually test.

Likewise, this unit review does not establish aircraft accuracy, sensor suitability, payload compatibility or mission permission. Those remain separate configuration and operational questions. Keeping these boundaries explicit prevents a useful data-management article from becoming an unsupported performance statement about the UG32.

A lesson for mixed-generation project records

Our editorial lesson is to preserve the original unit truth even when the project wants a modernized output. A legacy declaration is evidence about the source, not an inconvenience to remove. The receiving team should be able to explain both what the original values meant and what the reviewed output is intended to mean.

A practical handover meeting can end with three clear outcomes: the definition is confirmed, a responsible specialist has an agreed conversion task, or the evidence remains insufficient for the proposed combination. That is more useful than ending with a visually aligned screenshot and an undocumented assumption.

Make the UG32 inquiry specific

The UG32 product page identifies the aircraft being considered for a configuration discussion. The VTOL and fixed-wing collection offers the broader product category. Neither reference establishes that legacy conversion work, survey certification or processing software is included in a purchase.

Before sending an inquiry to UNITED UAV, gather the source unit declaration, the desired output reference system and a description of the receiving task. Ask which configuration and service details can be confirmed, which review belongs to your geospatial specialist and what sample evidence can be supplied. This turns a vague request for matching maps into a bounded conversation about data responsibilities.