A classified raster should be handed over with a resampling method that respects its pixel meanings. If values are category codes, smoothing them as though they were continuous measurements can undermine the legend. For a UG32 mapping inquiry, specify the required deliverable, the processing evidence and the receiving-system check separately from the aircraft configuration. A clean-looking map is not enough to approve the underlying data.

Imagine a receiving analyst opening a land-cover layer and seeing an attractive, smooth boundary between two classes. The project manager approves the screenshot. Later, another colleague inspects the stored values and finds codes that the agreed legend does not explain. This is a hypothetical acceptance problem, not a reported UG32 incident. It illustrates why the question at handover should be about what the raster contains, not simply whether its preview looks professional.

Start with the meaning of a pixel

Before requesting an export, have the author identify the kind of information in each band. A class label, an image channel and a measured surface value have different purposes. The buyer does not need to choose every processing option, but the buyer does need a written statement of the intended result. Otherwise the supplier and the receiving analyst may each make reasonable choices for different tasks.

For a categorical deliverable, ask for the class dictionary alongside the file. It should explain the accepted codes, their labels and the treatment of areas without a classification. Keep those statements together. A legend embedded only in a presentation slide is easy to separate from the data when files move between teams. The project should not depend on someone remembering which colors represented which classes during a meeting.

The official GDAL gdal_translate documentation distinguishes resampling options: nearest-neighbour samples values, bilinear uses interpolation, and mode selects the most frequent sampled value. Those descriptions explain why methods are not interchangeable. They do not prescribe one universal choice for every mapping product. In particular, a categorical code should not be treated as a meaningful intermediate measurement merely because a numeric operation can be applied to it.

Separate the analysis file from its display

A useful procurement brief names at least two possible outputs: the data that will be analysed and the view that will be read by people. They may be delivered together, but their acceptance questions differ. For the data file, ask whether the stored values and grid meet the receiving specification. For the preview, ask whether the legend and presentation communicate those values honestly. Do not let a convenient viewing setting quietly become a processing requirement.

This distinction also gives the supplier room to explain tradeoffs. A team may want a small review image for email and a separate authoritative raster for analysis. That is a reasonable discussion as long as the roles are explicit. Label the derivative as a review copy, identify the corresponding source package and avoid asking reviewers to infer data properties from the appearance of the smaller image.

Consider a hypothetical class dictionary in which code 1 means one surface type and code 2 means another. A stored value between those labels does not automatically define a useful third class. The arithmetic example is deliberately simple; it is not a description of a real survey. Its purpose is to make the receiving team ask whether the processing operation preserves the agreed meaning of the values it handles.

Make the target grid part of the conversation

Ask the recipient to describe the destination before the supplier prepares a large delivery. Useful questions include which layer will be compared with the new file, which grid or resolution the recipient expects, and whether an existing workflow imposes specific requirements. Record the answers as project requirements rather than treating the software's initial settings as the buyer's decision.

Do not bundle these questions into an unsupported promise of greater accuracy. A change in grid or presentation does not, by itself, establish that the original observations were correct. Keep positional review, class interpretation and processing review as separate evidence requests. The distinction helps a project manager send a question to the right specialist instead of asking the aircraft supplier to approve the entire downstream analysis.

The same habit is useful for elevation work. Our UG73 guide to height references considers a different kind of ambiguity: values can share a unit without sharing a reference. A complete receiving specification should explain both the meaning of a value and the context needed to interpret it. Neither task is solved by a more polished screenshot.

Review a small boundary sample before the full handover

Our editorial recommendation is to request a representative excerpt that includes a class boundary and an unclassified area. Have the receiving analyst open it using the intended workflow and inspect the actual values. The exercise should answer a narrowly defined acceptance question: does this sample behave as the agreed class dictionary and delivery specification say it should? It is not a substitute for a complete quality assessment.

Ask the supplier to identify the processing method, the relevant settings and the file to which that explanation applies. Ask the recipient to record what was checked and what remains outside the review. A short record of a real inspection is more useful than a generic statement that the export is compatible. It also makes later questions easier to resolve without reconstructing a chain of informal conversations.

Keep an unresolved sample unresolved. If the analyst cannot explain an unexpected code, do not rename it to the nearest familiar label merely to close the review. Request clarification from the person responsible for the processing. The appropriate response might be a corrected export, a revised specification or an explanation of a valid but previously undocumented class. The acceptance process should distinguish those possibilities.

A practical field-handover lesson

The useful habit is simple: ask someone to read a pixel value at a boundary before asking everyone to admire the map. That is a proposed review practice, not a claim about a customer experience. It makes the conversation concrete. A project manager can point to a specific file, location and expected interpretation, while the analyst can explain whether the delivered values support that interpretation.

Build the lesson into the handover agenda. Reserve time for the receiving team, not only the producing team, to demonstrate its understanding. Have one person identify the authoritative file and another identify the matching legend. If they choose different versions, resolve that mismatch before discussing visual refinements. The result is a clearer record of what has actually been accepted.

Where UG32 fits in the inquiry

The UG32 fixed-wing VTOL UAV product page is the starting point for an aircraft configuration discussion. It is not evidence that a particular classification package, GDAL installation, export setting or GIS service is supplied. Ask UNITED UAV which configuration details and supporting documents are available, and ask the proposed processing provider to address the raster requirements. Keep responsibility for those answers explicit.

A buyer comparing the wider VTOL and fixed-wing drone collection should carry the same deliverable brief between aircraft discussions. That prevents the core requirement from changing whenever a different model is considered. Product selection, payload integration and downstream data acceptance belong in the same project plan, but they are not interchangeable approvals.

If the intended output concerns crops, start even earlier with the observation being requested. Our UG62 article on NDVI and RGB mapping requirements explains why the named output must match the information being acquired. A processing method cannot make an incomplete evidence request into a well-defined mission.

Questions to settle before requesting the final package

A useful acceptance note can be very short. Record the sample filename, the class dictionary version, the recipient's stated requirement and the outcome of the inspection. Add the reviewer and the unresolved question, if there is one. That record tells the next person whether they are looking at a passed check, an open question or an example that was never intended for acceptance.

Keep a change in class meaning distinct from a change in color. If the project team decides to revise the legend, ask how earlier and later packages will be distinguished. Do not ask the supplier to preserve an obsolete definition simply to avoid a new review. Instead, make the change explicit and let the appropriate recipient decide which parts of the handover need checking again. This keeps version control connected to the meaning of the data rather than just its filename.

• Which values are categories, and where is the accepted class dictionary?
• Which file is authoritative for analysis and which is a display derivative?
• What target grid and processing method does the recipient require?
• Who will inspect representative boundary and unclassified-area samples?
• Who can approve an exception, and how will that decision be documented?

These questions are intentionally about acceptance evidence rather than a particular button sequence. Software versions, project methods and responsibilities can differ. The specification should remain intelligible to a reviewer who was not present when the export was made. That is also why an unexplained screenshot should not become the only surviving record of the decision.

For a focused next step, send UNITED UAV your UG32 configuration inquiry with the class legend, intended recipient and a description of the required sample file. Identify the processing questions that still need a specialist answer. The goal is a bounded configuration conversation and a demonstrable handover requirement, not a promise that one aircraft choice guarantees correct raster analysis.