A raster clipped to a bounding box is not necessarily clipped to the actual project polygon. For a UVH1 mapping inquiry, define which pixels may remain outside an irregular boundary, how internal exclusions are represented, and what evidence the recipient will inspect. A tidy rectangular file is a delivery container, not proof that the requested area was acquired or accepted.

What does your team mean by clipped?

Imagine a project shaped like an L. A rectangle surrounding that shape also contains a large corner that does not belong to the project. Two suppliers can therefore deliver files with identical outer dimensions while providing different spatial content. One retains values throughout the rectangle. Another keeps values only inside the L and marks the remaining cells as invalid. Neither result can be judged against a request that merely says to clip the map.

This is an original buyer-scoping example, not a reported UVH1 mission. Its purpose is to expose an acceptance question before an aircraft or processing package is selected. The buyer needs to decide whether the contract concerns a rectangular export, a polygon-limited analysis surface, or a presentation that conceals information outside the boundary. Those are separate deliverables, even when their screenshots look similar.

The software distinction is explicit

Esri's Clip Raster documentation for ArcGIS Pro 3.3 distinguishes clipping with feature geometry from using the features' enclosing extent. It also describes an extent-maintenance choice that can resample the output, versus preserving alignment and adjusting the extent. These are software-specific controls, not claims about UVH1 processing compatibility. Ask the proposed processor to identify equivalent behavior in its actual tool and version.

The useful procurement lesson is to ask for observable output behavior instead of naming a button from someone else's software. A receiving analyst should be able to answer whether an outside cell contains a usable value, whether the intended exclusions survived, and whether the delivered grid matches the agreed reference. Record these answers in the acceptance note, rather than assuming that a familiar command name settles them.

Separate the three boundaries

A project boundary describes what the customer wants included. An acquisition footprint describes where the underlying observations exist. A delivery extent describes the area occupied by the exported dataset. Keep all three concepts visible in the scope. A processing operation can change what is retained in a file without demonstrating that the original observations meet the customer's coverage or quality requirements.

For example, a project owner might exclude a courtyard from the final analytical product while still receiving a broad contextual preview. That is a delivery decision. It should not silently become a statement about where an aircraft may operate, what data may be collected, or whether an operational permission exists. Flight planning and applicable permissions require their own review; this article addresses the data handover only.

Test the awkward locations first

A broad overview is a weak place to start a boundary review. Our editorial recommendation is to choose a concave corner, a narrow extension and an internal exclusion before viewing the whole project. These locations reveal whether the buyer and supplier mean the same thing by inclusion. A rectangular project with no exclusions is a poor demonstration of how an irregular boundary will be handled.

Agree the expected treatment of cells intersected by the boundary as well. Do not turn a sample check into an undocumented universal tolerance. The processing specialist should explain the chosen cell-inclusion rule, the delivered grid and any transformation applied to the boundary. The buyer can then decide whether that behavior suits the intended analysis. An attractive edge on a preview cannot substitute for that agreement.

Keep the test small enough that a second reviewer can repeat it. Supply the boundary sample, identify a handful of inspection locations and retain the recipient's observations. A disagreement should produce an explicit scope decision, not a sequence of increasingly polished screenshots. Once the parties agree, use the same checks on the final package and record any approved departure from the sample.

Make the receiving workflow part of acceptance

The person viewing the map may not be the person using its values. Ask both roles to participate. A presentation reviewer may be satisfied when the project outline is visually clear, while an analyst needs to know whether outside cells enter a later calculation. Write the acceptance task in terms of the recipient's actual use, such as comparing an included point with an excluded point in the delivered dataset.

Retain a short record of the receiving application, import choice and inspected file. This is not a requirement to standardize everyone on a particular GIS package. It is a way to distinguish a delivery defect from a difference in how the recipient opened or displayed the data. Where several applications are in scope, agree which results must be equivalent and which presentation differences are acceptable.

Do not hide gaps by redefining the boundary

If an area lacks acceptable source information, shrinking the delivered boundary can make the package appear complete without resolving the original scope. Require the supplier to identify that exception openly. The buyer may approve a reduced area, request further work, or accept a clearly limited product. Each choice should remain traceable to the original request, rather than disappearing into a replacement polygon with the same filename.

Boundary handling is also separate from filling missing terrain values. A continuous surface may contain estimates, while an irregular edge may simply express the intended project scope. Review the distinction in UG73 terrain deliverables and interpolation provenance when the package includes elevation data. Do not treat either clipping or filling as automatic evidence that a mapping requirement has been met.

Keep revision control practical

Choose one named boundary revision for quotation and another only when a change is formally accepted. Record who supplied the change, why it changed and which deliverables need regeneration. A supplier should not have to infer whether an emailed sketch replaces the signed scope. Equally, a buyer should not discover at handover that an early draft boundary controlled the processing.

A useful change note can be short: identify the old and new boundary, list the affected deliverables and state whether the acceptance sample must be rerun. Preserve the earlier files rather than overwriting them. This protects the conversation from ambiguity without creating a large administrative process. It also makes an additional processing charge easier to evaluate against a clearly defined change.

Where UVH1 fits in the inquiry

The UVH1 product listing provides the approved product identity for a configuration discussion. It does not establish that a particular camera, GIS license, processing service, boundary workflow or mapping accuracy is included. Treat those items as questions to be answered in the proposed configuration and scope of supply. For unconfirmed specifications or integration details, contact us for configuration details.

Start with the intended output, receiving software and sample boundary, then discuss aircraft and payload suitability. This sequence helps distinguish an aircraft requirement from a processing or acceptance requirement. Buyers in the United States and Ireland can use the same data-scoping questions while keeping their operational and jurisdictional reviews separate. No local approval or project suitability is implied by the example.

Questions to settle before quotation

Must the delivered file itself have a polygon shape?

Ask instead which locations must contain usable values and which must not. That is an inspectable requirement. The proposed file format and processing method should then explain how the requirement is represented. Do not make the screenshot outline the only acceptance criterion.

Does clipping confirm coverage?

No. Request coverage evidence separately and define who approves exceptions. A boundary-conforming output can still require a quality review inside its accepted area. Keep the coverage decision, processing decision and final acceptance decision identifiable in the handover record.

What about photographs linked to mapped assets?

They need their own completeness check. A correct raster boundary does not prove that associated inspection media survived export. The companion UG32 GIS attachment handover guide focuses on that different relationship between spatial records and supporting files.

Bring a boundary example, not just an area total

Before comparing options in the VTOL and fixed-wing drone collection, prepare a small project polygon with one awkward edge and one exclusion. Add the intended output type, receiving application and expected behavior at those locations. This makes the request more specific than a coverage-area figure alone and gives the configuration discussion a concrete decision to resolve.

Use the UNITED UAV inquiry channel to request a boundary-focused scoping discussion for UVH1. Ask which requirements belong to the aircraft package, which need a payload or software confirmation, and which remain the responsibility of the processing supplier. The next step is an agreed evidence test, not an assumption that the word clipped means the same thing to every participant.