Where raster tiles overlap, ask which source supplies the delivered cell value or which explicit calculation combines the inputs. A visually continuous mosaic does not answer that question. For a UG73 mapping inquiry, preserve the source list, its priority order, the processing configuration and representative overlap checks. Keep those records with the final output so a recipient can trace a disputed value without guessing from the map's appearance.

One Location, More Than One Candidate Value

Imagine an illustrative handover containing overlapping tiles from two approved source deliveries. Both cover part of the same area, but their values differ at a review location. The processor builds a mosaic and supplies one output value there. The buyer now needs to know whether the value came from one tile, a calculation across tiles or another documented rule. The answer matters even if the display has no visible join.

This is a hypothetical data-acceptance problem, not a claim about an actual UG73 survey. It concerns the processing and handover specification. It does not establish that a particular aircraft configuration includes a mosaic service or that the source measurements are suitable for the buyer's intended use.

Identify the Actual Processing Rule

The official GDAL gdalbuildvrt documentation states that, without an explicit pixel function, later-listed inputs take priority in overlaps. Nodata can permit fallback to a lower-priority source. The documentation also distinguishes that behaviour from alpha compositing and notes explicit overlap pixel functions introduced in GDAL 3.12. These details describe the cited tool and configuration, not every mosaic application.

Ask the supplier to name the actual software, version and relevant settings. Do not assume that a file labelled mosaic was produced by the documented default or that a newer software version was used. If another application is involved, request its corresponding technical evidence. The acceptance record should describe what happened, not what a buyer thinks normally happens.

The recommendations below are original editorial analysis about specifying that evidence. They are not a universal recipe for choosing the scientifically correct overlap rule.

Decide What the Mosaic Is Meant to Represent

Before ranking sources, define the intended information product. A display assembled for convenient viewing may have a different purpose from a numerical surface used in a later calculation. A mosaic intended to represent one approved delivery should not silently mix in an older source just because both files happen to be available. State the permitted source set and who can authorize additions.

If the buyer wants a preferred source in certain areas, identify the basis for that preference. It might be an approved revision or a contractual source designation. Do not invent a rule that the newest file is always best. File modification time, acquisition time and approval status can describe different things. The project needs a deliberate policy and enough metadata to apply it.

Where the correct policy is unresolved, record the question before building an output that hides the disagreement.

Preserve More Than Filenames

A source manifest should identify each input sufficiently to distinguish it from another file with the same name. Record a stable file identity, its role in the build and its position in any ordered list. Keep the exact list used for the accepted output. If a processor discovers inputs automatically from a directory, ask how the resulting order is made explicit and preserved.

Also record the output identity and the processing configuration. A source list alone cannot explain a build that applied a different overlap function, mask treatment or other relevant setting. The buyer does not need a screenshot of every software dialogue; the goal is a compact record that a qualified reviewer can use to understand and, where agreed, reproduce the output.

A change to source order should be treated as a processing change when order affects the result. It should not disappear inside an undocumented rerun.

Treat Missingness and Visibility Separately

Ask the supplier to identify the valid-data rules of the inputs and explain how those rules enter the selected process. A transparent-looking preview is not sufficient evidence of which values a numeric reader will use. Request a representative example where a preferred input lacks valid data, with the expected result and the observed output documented by the processor.

Do not declare a convenient number to be missing merely because it makes the image look cleaner. The validity definition must come from the source specification and the intended measurement meaning. If a value has been reclassified, retain the reason and approval. Otherwise, an apparent improvement in the mosaic can conceal a change in the information supplied.

Keep display styling out of the acceptance evidence for cell values. A colour map can assist inspection, but the recipient should be able to examine the relevant numerical or categorical values directly.

Select Review Locations With a Purpose

Choose overlap locations that exercise the rule being claimed. Include a straightforward overlap between two valid sources and, where relevant, an area involving an approved exclusion or missing-data condition. Record the location definition precisely enough that both parties inspect the same output cell or agreed review area. Avoid comparing screenshots taken at different scales and treating a visual discrepancy as a proven value discrepancy.

Ask the processor to trace each example through the source manifest and configuration. The report should show the candidate inputs, the applied rule and the delivered result. Label any synthetic demonstration separately from project data. A manufactured example can clarify the rule without pretending to establish the quality of the real survey.

These checks demonstrate selected cases. They do not replace a complete quality plan for source accuracy, coverage or the suitability of the mosaic for a downstream decision.

Keep Revision Control Close to Acceptance

A replacement tile can change only a small region while leaving the rest of the mosaic visually familiar. Ask how such updates are recorded and which checks are repeated. The recipient should know whether the delivered mosaic reflects the original source set or an amended one. A stable filename is not a substitute for a version identity.

Request a short change note describing the approved input replacement, the affected scope and the resulting output. If an earlier report is superseded, identify that explicitly. This helps a downstream team avoid mixing a new raster with an old acceptance record or assuming that a previous review covers a newly introduced source.

Ask how the recipient will be told that an output has changed. A revised download without an accompanying notice can leave different departments using different mosaics under the same informal project name. Identify the release owner and the delivery record that announces the new version. This is a handover-control question, not a demand for any particular hosting platform. The important evidence is that the accepted version can be distinguished from the one it replaces.

The practical lesson is to treat source order and overlap settings as part of the deliverable's provenance. This is an editorial recommendation, not an operator testimonial.

Connect the Mosaic to Later Deliverables

If the mosaic informs a polygon output, the polygon coverage review addresses a different acceptance question: how adjoining features relate and whether they cover the required footprint. If inputs feed a classifier, the feature-importance review addresses interpretation of a fitted model's reliance on those inputs. Neither downstream result removes the need to identify the raster values that entered the workflow.

Assign ownership across the chain. The source provider, mosaic processor and final reviewer may be different organizations. Ask each to confirm the evidence it will supply. An unowned handover step should remain an explicit dependency rather than becoming an assumed service bundled with the aircraft.

Frame the UG73 Product Discussion Carefully

The UG73 fixed-wing VTOL product page supplies the approved product identity for a configuration inquiry. This article does not verify an included camera, processing application, source-priority policy or mosaic service. For unconfirmed facts, contact us for configuration details. Ask for the exact proposed equipment and service scope before connecting it to your deliverable requirements.

Use the VTOL and fixed-wing collection to compare aircraft options while maintaining a separate processing brief. The desired map can guide the questions, but its requirements are not proof that a product automatically satisfies them. Keep confirmed inclusions, options, buyer responsibilities and unresolved technical items distinct.

Questions That Make the Review Concrete

Does a seamless display prove the preferred source was used? No; inspect provenance and values. Does input order always matter? It depends on the actual tool and overlap configuration. Should overlap values always be averaged? No universal choice follows from this article; the project must justify the intended information product. Can an accepted mosaic be rebuilt from its record? Ask for the agreed level of reproducibility and the dependencies needed to demonstrate it.

Prepare an ordered source list, the proposed overlap policy and one location where the choice affects your decision. Send them through the UNITED UAV inquiry page to request a scoped configuration and processing discussion. Ask for a traceable acceptance sample and a clear account of what remains unverified. The useful answer is not simply that the tiles have been merged; it is an explanation of which information survived the merge and why.