A point cloud can render convincingly while a required custom attribute is absent from the delivered file. For a UG39 lidar-system inquiry, define the extra point dimensions that must survive export and request a recipient-side round-trip check. File opening, point count, and a screenshot are not substitutes for checking the named fields that the next processing step actually needs.

The Missing Field May Not Change the Picture

Consider an illustrative handover in which the supplier displays a cloud using position and color, while the buyer expects a project-specific review attribute for a later workflow. Both parties look at the same attractive view and agree that the file opens. Only after delivery does the buyer discover that the expected field is unavailable in the receiving application. This is a hypothetical procurement example, not a reported UG39 deployment.

The problem is a mismatch between a visual demonstration and an information requirement. The buyer did not merely purchase a picture of points. The requested deliverable included named values associated with those points. Whether a proposed workflow can preserve and interpret those values needs its own evidence, independent of whether the geometry looks reasonable.

This distinction is useful for survey data managers comparing sensor and processing proposals. It does not establish that UG39 includes a particular lidar, creates custom attributes, or supports a particular software chain. Treat the aircraft, payload, processing service, and data handover as separate scope items until the supplier confirms the offered configuration in writing.

What the LAS Writer Documentation Establishes

The official PDAL LAS writer documentation describes an extra_dims option for dimensions outside the standard point format. Its entries identify dimension names and types, while an all option covers nonstandard dimensions. The writer documents extra dimensions through an Extra Bytes variable-length record. Reader behavior and LAS-version handling still matter; a writer setting alone is not a demonstration of the recipient's interpretation.

That source supports a narrow technical distinction: extra dimensions are an explicit part of the export schema, not something a buyer should infer from a rendered cloud. It is not evidence that any specific supplier uses PDAL, that all LAS readers behave identically, or that a third-party application is compatible with UG39. The procurement recommendations below are editorial analysis built around that distinction.

Write a Dimension Dictionary Before the Export

Start with the fields needed by the receiving workflow. For each field, record the agreed name, meaning, unit where applicable, intended type, valid interpretation, and treatment of missing information. Identify whether the value is a measurement, a processing result, or an editorial label. A name such as quality is too vague if two teams use it for different judgments.

Require the supplier to mark which requested fields are actually available. A field that cannot be supplied should remain an explicit scope exception, not become an empty column with an encouraging name. If a proposed substitute is useful, the buyer should approve its meaning before delivery. Renaming an existing field does not by itself make it equivalent to the requested information.

Also identify who owns the dictionary. The acquisition provider may know how a value is produced, while the recipient understands what its software expects. The accepted dictionary needs both perspectives. Keep its revision alongside the export configuration and sample file so that a later review can identify exactly which agreement was tested.

Include a short distinction between required and optional fields. Required fields should have an acceptance result. Optional fields can have a documented availability statement. This prevents a large list of desirable attributes from disguising a small missing field that the actual downstream decision depends on.

Test the Recipient's Actual Reading Path

Ask for a small representative sample to pass through the proposed delivery and receiving steps. Name the receiving application and version, the import path, and any conversion performed before inspection. A sample opened in the supplier's preferred viewer is useful context, but it does not answer whether the buyer's designated workflow exposes the required dimensions correctly.

The review record should compare named attributes on matched points. Agree how the reviewer identifies corresponding points after any permitted transformation; do not assume file order is a stable identifier. If correspondence cannot be established, record that limitation and revise the test design with the processing specialist. A plausible distribution of values is not equivalent to evidence about the same observations.

Use examples that exercise the agreed meanings rather than selecting only ordinary values. Depending on the requested field, the review may include an unavailable entry, a boundary category, or an uncommon label. The responsible specialist should choose suitable cases. This article does not prescribe numerical tolerances or invent the range of any proposed sensor output.

Capture both the delivered schema and the recipient's observed interpretation. If the recipient displays a field under a different name, document the mapping. If a conversion changes its representation, explain whether the approved meaning remains intact. The acceptance owner should sign off on the actual result, not on a statement that the software usually supports extra attributes.

Separate Preservation From Meaning

A field can be present yet still be unsuitable for the buyer's purpose. For example, a project label may need a dictionary that is absent from the delivery. A numerical column may be visible without a clear unit or missing-value convention. These are illustrative documentation gaps, not claims about a particular file format or product.

Ask the provider to distinguish exact preservation from an approved transformation. When values are deliberately recoded, the delivery should identify the rule and its owner. When values are omitted, the omission should appear in the exception list. The buyer then has a reviewable decision instead of having to guess whether a difference is intentional or accidental.

Do not request a field merely because it exists in an intermediate file. First explain the decision it will support and whether the receiving team can use it responsibly. Unnecessary attributes can complicate a handover without improving its purpose. Conversely, a seemingly small field should not be removed just because it does not affect the standard visualization.

Make the Acceptance Pack Specific

A practical evidence pack can contain the accepted dimension dictionary, sample input and delivered output identifiers, export configuration, receiving software details, matched-point comparison, and unresolved exceptions. Ask the provider which artifacts it can deliver and what effort is included. These are proposed purchasing requirements, not a claim that every processing service supplies them automatically.

Require a clear result for each essential field: demonstrated, demonstrated with an approved transformation, unavailable, or unresolved. Avoid a single green badge covering the whole file. The purpose is to make partial success understandable. The buyer can then decide whether an exception is acceptable, needs rework, or prevents the intended use.

Agree what must be repeated after a software or export-setting change. A previous sample review should not silently stand in for a changed configuration. The parties can choose a proportionate retest scope, but the reason for that scope should be recorded. Keeping the configuration revision attached to the evidence makes that discussion concrete.

The field lesson is simple: inspect the required information, not merely the artifact that carries it. This is editorial buyer analysis, not an invented account of field experience. A screenshot can establish that a view was produced. It cannot alone establish preservation of every attribute needed by a separate analytical workflow.

Keep Related Decisions Separate

When a project also delivers classified maps, review small-patch cleanup in classified rasters as a separate transformation with its own change evidence. Preserving attributes in a point file does not prove that a later map retained every important feature. Each requested transformation needs a defined input, output, and acceptance purpose.

For a broader acquisition-chain proposal, the discussion of settling between multiplexed sensor channels addresses another boundary: whether the measurement configuration itself was demonstrated. A successful export cannot validate the acquisition process, just as a successful acquisition demonstration cannot prove that every requested delivery field survived processing.

Bring the Schema to the UG39 Inquiry

Plan the review before scheduling a full delivery. Assign the recipient enough time to test the sample in its own environment and return specific exceptions. A late discovery that the intended reader hides a required field can create avoidable commercial disagreement. An early sample review does not eliminate every delivery risk, but it exposes this particular information requirement while the scope and acceptance terms can still be clarified.

Use the UG39 fixed-wing VTOL product page for approved product identity, and the VTOL and fixed-wing collection to frame the aircraft comparison. Neither link is evidence of an included lidar, custom processing service, or particular extra-dimension capability. For unconfirmed payload, software, integration, and support arrangements, contact us for configuration details.

Send the required-dimension dictionary, intended receiving software, representative workflow, and acceptance owner through the UNITED UAV inquiry page. Ask which parts of the proposed chain can be demonstrated and which remain outside the offer. A useful response should identify the sample round trip, its evidence, and the unresolved questions before the buyer commits to a full delivery whose appearance may conceal missing information.