Before accepting a lidar proposal, state whether intensity is needed for visual interpretation or a quantitative comparison. Then require a definition of the delivered attribute, its processing history, and evidence supporting the intended use. For a UG39 inquiry, keep that data requirement separate from aircraft and payload feasibility; an intensity field does not prove calibrated comparability or a supported integration.

Start with the decision, not the color ramp

A striking point-cloud display can make a proposal feel complete. Light and dark surfaces appear distinct, and the customer can imagine using those differences to make a decision. But the image alone does not tell the buyer whether the display is a viewing aid, a processed comparison, or evidence suitable for a particular material interpretation. Those are different commitments and should not share one vague line item.

Write the intended decision in plain language. Perhaps a reviewer wants another visual clue while examining a mapped area. Perhaps an analyst proposes comparing observations from separate acquisitions. The second request needs a much more specific explanation of comparability. This article does not validate either use for a particular sensor or site; it helps the buyer ask what the supplier is actually offering.

What the attribute name does and does not mean

The USGS Lidar Base Specification glossary describes discrete-return intensity in terms of recorded return amplitude and discusses influences including gain and incidence geometry. It cautions against treating such values as a direct measurement of reflected energy without the necessary qualification. The glossary is useful terminology, not proof that a proposed dataset has been calibrated or that different acquisitions are comparable.

The procurement implication is to request the supplier's own definition for the exact output being quoted. Ask whether the delivered field retains an original attribute or contains a derived value, what operations changed it, and which claims the supplier is prepared to support. A reference to a general standard should accompany that explanation rather than substitute for it.

Do not let a field label carry an unstated performance promise. A supplier can accurately say that an output contains intensity while declining to support a quantitative material comparison. That may be entirely suitable for the buyer's viewing task. The problem arises when a purchasing team credits the proposal with an analytical capability that nobody has demonstrated or priced.

Separate three records in the delivery scope

Our recommended structure is to request a data record, a processing record, and a display record. The data record identifies the attribute being supplied. The processing record explains how the delivered values relate to their source. The display record states how a particular preview was presented. This is an editorial contract structure, not a mandatory data standard.

Require enough detail for the intended recipient, not an indiscriminate export of every internal processing log. If the analyst cannot explain how a requested record changes acceptance, simplify the request. Conversely, if an important transformation remains unexplained, keep the analytical use unresolved even when the preview looks persuasive.

Design a bounded supplier demonstration

Ask for a representative sample tied to the proposed output, with its provenance and limitations. The buyer and responsible specialist should agree what the sample can establish before the presentation. A generic marketing dataset can demonstrate a software interface, but it should not be treated as validation of an untested sensor and aircraft combination.

For a visual interpretation task, the specialist might review whether the delivered field can be displayed and understood within the agreed workflow. For a proposed comparison, the specialist should define the evidence required to support that comparison. Do not invent a universal numerical tolerance, calibration method, or pass threshold in a procurement article. Those decisions depend on the actual measurement chain and purpose.

When a demonstration includes several acquisition groups, ask the supplier to identify them in the review materials. If a visible boundary appears, the reviewer should be able to investigate its context rather than assume that it represents a change in the ground material. This is a question to resolve with evidence, not a conclusion that every boundary is an error.

Keep the attribute and the preview apart

A practical editorial lesson is to preserve the unrendered attribute and the settings used for its display as separate review records. Otherwise, a more dramatic contrast can be mistaken for a more informative measurement. This is a proposed acceptance habit, not an account of an actual UG39 deployment or an attributed operator observation.

During a review, ask the presenter to identify which changes affect only the view and which changes produce a new delivered dataset. Record the distinction in the meeting notes. If the customer later requests the appearance shown in a presentation, the supplier can clarify whether that means a saved visualization, a processing change, or a separate analytical product.

Retain a stable sample for the acceptance discussion. Replacing the sample midway through a meeting makes it difficult to determine whether a difference comes from the data, the presentation, or the selection of another area. A stable sample is not a complete quality program, but it gives participants a common object for resolving the specific question at hand.

Compare quotations by supported use

Consider two hypothetical offers. One provides a point cloud with a documented intensity field for visual review. Another proposes a processed attribute for a defined comparison and includes the specialist evidence needed to defend that use. The second is not automatically better; it is broader. The buyer should compare each offer against the decision it actually needs to make.

Ask each bidder to identify exclusions. A clear statement that a deliverable is not validated for a requested quantitative interpretation is useful procurement information. It allows the customer to seek a separate analysis service or revise the requirement. An unexplained promise of consistent intensity is less helpful because it leaves the meaning of consistency open.

For a United States project, citing USGS terminology can help participants use the same vocabulary without asserting that the project is a USGS program. For a New Zealand receiving team, agree the recipient's required fields and evidence directly rather than importing a foreign specification by name. The applicable project requirements remain the buyer's and specialist's responsibility.

Connect intensity acceptance to the wider handover

If a survey package includes editable GIS layers, the GeoPackage closeout checklist addresses whether the recipient receives the agreed released state. That is different from establishing what a lidar attribute means. Keep both questions in scope if both deliverables are being purchased, with a named owner for each acceptance decision.

A similar distinction appears in environmental reporting of non-detects and limits: a value should travel with enough context to support its intended interpretation. The scientific issues differ, so the checklists are not interchangeable. Their shared procurement lesson is to avoid reducing a qualified observation to an unexplained number in a handover table.

UG39 is a configuration inquiry, not a lidar commitment

The UG39 listing identifies an aircraft in the VTOL and fixed-wing collection. It does not establish that a lidar sensor is included, mechanically compatible, electrically compatible, supported by a processing workflow, or approved for a particular mission. A proposed integration needs its own written feasibility review and scope.

Keep aircraft selection, payload selection, data processing, and analytical interpretation as explicit quotation components. Ask which organization owns each component and how unresolved dependencies affect the offer. If the payload is not yet selected, it is premature to promise a particular intensity deliverable merely because a sample from another system looks useful.

A staged evaluation can help when the intended use is clear but the implementation is not. Request a priced feasibility or sample-review step before committing to a larger deliverable package. Define what decision that step will support, who will assess it, and what remains outside its scope. Do not describe a preliminary demonstration as production validation.

Questions to take into the supplier discussion

Does intensity mean reflectance? Do not assume equivalence from a field name. Ask the responsible specialist what the delivered quantity represents and which interpretation is supported by the processing and validation evidence.

Is a consistent-looking preview enough? It can help a viewing discussion, but acceptance should use the evidence agreed for the intended task. A quantitative comparison needs a defined basis beyond an attractive display.

What should the initial brief contain? Send the intended intensity use, receiving software, required output fields, and evidence questions through the UNITED UAV inquiry page. Request an aircraft configuration discussion with payload feasibility and data-processing obligations listed separately, including every dependency that has not yet been confirmed.

Source checked 13 October 2026. Buyer examples are editorial analysis; no sensor integration, calibration, survey accuracy, or regulatory acceptance is claimed.