A coordinate column can display many decimal places while telling you nothing about how closely the points represent the surveyed object. For a UG39 survey inquiry, keep LAS coordinate encoding and accuracy evidence in separate acceptance items. Ask how coordinates are stored and interpreted, then request independent support for any accuracy claim. Extra digits are not a reason to select an aircraft, payload or processing service.

This guide addresses the review of a proposed point-cloud deliverable. It does not state that a UG39 configuration includes LiDAR, a particular positioning system or a supported LAS workflow. Those inclusions require written confirmation. The procurement problem is narrower: a buyer needs to distinguish a file's representation of coordinates from evidence about the measurements represented by that file.

The question a decimal column cannot answer

Suppose a fictional quotation includes a sample table with coordinates printed to six decimal places. The sample may be useful for discussing an export format, but it does not identify the measurement method, evaluation conditions or acceptance evidence. Our recommendation is to treat the table as a format example until the supplier provides the separate information needed to evaluate the underlying claim.

Ask the supplier what the digits mean in that specific delivery. Are they a display convention, the result of a storage setting or a requirement of a downstream exchange? Keep the answer with the sample. Do not convert an explanation about a file format into a conclusion about the aircraft or the accuracy of a survey.

The same discipline applies to a visually smooth point cloud. Appearance may help a reviewer orient themselves, but a procurement decision should use the evidence specified for the intended task. Agree who is qualified to evaluate that evidence. A purchasing administrator can check whether a required report exists without claiming to have independently validated its technical conclusions.

What scale and offset are doing in LAS

The PDAL LAS tutorial explains that LAS coordinates are stored as integers and interpreted using scale and offset values. Its coordinate-scaling discussion warns that storing precision beyond the collection resolution can mislead readers about actual measurement precision. This is an explanation of coordinate representation, not a UG39 performance specification.

For a buyer, the practical request is a documented encoding convention for each coordinate axis, together with the coordinate reference information needed by the intended recipient. Ask the data provider to explain the chosen settings and demonstrate the agreed sample in the receiving software. Do not prescribe arbitrary settings merely to obtain a longer-looking number.

Keep storage settings out of the accuracy scorecard unless a qualified reviewer has explained their relevance to a specific requirement. A file can satisfy an encoding requirement while lacking the evidence needed for an accuracy requirement. It can also arrive with useful accuracy evidence yet require clarification about how the recipient should interpret its coordinate representation.

Use two acceptance rows instead of one

Our proposed procurement checklist separates representation from evidence. The first row asks whether the delivery's coordinate storage, reference information and intended exchange behavior are documented. The second asks whether the supplier has provided the agreed evidence for its measurement claims. The rows can have different owners, review methods and unresolved questions.

This structure helps a team discuss a gap precisely. Rather than saying the data is not good enough, the recipient can state that the encoding explanation is missing, the sample cannot be interpreted as agreed, or the claimed accuracy lacks the specified support. Precision in the procurement language reduces the temptation to substitute one attractive piece of evidence for another.

A fictional exchange review

Consider a receiving team that requests a small, permitted LAS sample from a prospective data provider. The supplier identifies the sample revision and explains its coordinate representation. The GIS recipient opens that exact file in the intended application and records the interpretation shown. The technical reviewer separately examines the agreed accuracy evidence. No one uses the number of printed decimal places as a pass condition.

Now imagine the application displays fewer digits than a supplier's screenshot. That difference should trigger a question about display and interpretation, not an immediate claim that measurements were lost or improved. Ask the supplier and recipient to trace the agreed sample through their workflows. Document their explanation and keep the review bounded to what was actually checked.

This scenario is a suggested handover exercise, not a customer case or a validated survey test. It gives the purchasing team a way to assign questions. Any conclusion about whether a transformation or export preserved the required information belongs with the qualified technical reviewer and the agreed evidence, not with a visual comparison of two screenshots.

Write a sample request that can be fulfilled

Identify the recipient software and the purpose of the review. Request a sample whose content can be shared lawfully and whose delivery conditions are clear. Ask the supplier to include a file index, the coordinate-reference explanation, the relevant encoding settings and a contact for interpretation questions. Sensitive project data need not be disclosed to make the scope intelligible.

Specify what the recipient will return: a receipt record, an opening or interpretation result and a list of unresolved issues. This makes the exercise a defined exchange rather than an open-ended request for free analysis. Agree whether any additional compatibility work or specialist review is included, separately priced or outside the proposed engagement.

Retain the original sample and its identification throughout the review. If the supplier issues a revised file, request a clear revision note instead of silently replacing the earlier one. Our suggested record should allow a later reader to understand which file was examined and which conclusions apply to it. That is a documentation recommendation, not a guarantee of data integrity.

Ask who owns the accuracy claim

A proposal may involve an aircraft supplier, an integrator, a collection contractor and a processing provider. Ask which party is making each performance statement. The answer should identify the configuration and evaluation scope to which the statement applies. A general description of a file format should never be presented as support for a configuration-specific accuracy promise.

Have the buyer's qualified reviewer define the required evaluation evidence before quotations are compared. This article deliberately does not prescribe a tolerance, test procedure or acceptance threshold. Those choices depend on the intended use and the responsible professional's requirements. The purchasing task is to make the requirement and evidence owner visible.

Where a supplier cannot provide the requested evidence, record the limitation directly. Do not fill the gap with assumptions about the number of coordinates, the appearance of the point cloud or the sophistication of the equipment. A documented exclusion may be manageable; an unsupported conclusion hidden inside a comparison table is harder to evaluate.

Connect this review to the wider handover

The UG25 raster-preview guide addresses a related distinction between a convenient view and the source material required for acceptance. For point clouds, the same purchasing discipline means identifying the actual delivery under review, while recognizing that the format and technical checks will differ.

When supplier evidence uses terms such as repeatability or reproducibility, consult the UIV2200 sensor-evidence discussion. Consistency under stated conditions and accuracy are different questions. Request the evaluation scope rather than combining every reassuring term into a single unsupported quality judgment.

For the procurement record, link these questions rather than merging them. One index can point to the sample, the encoding explanation, the accuracy evidence and the acceptance note. Each item should still state its own purpose. This allows a recipient to find the supporting materials without assuming that passing one review closes all the others.

Place UG39 in the correct part of the proposal

The UG39 listing is a starting point for a product configuration discussion within the VTOL and fixed-wing drone collection. Confirm the proposed platform, payload arrangements and any separately commissioned data services in writing. No numerical aircraft performance, LiDAR inclusion or software compatibility is asserted here.

Our editorial procurement lesson is to keep coordinate encoding and accuracy evidence as separate acceptance items. The first helps the recipient interpret the supplied data. The second supports a claim about the measurement result. A well-scoped quotation should make it possible to ask for either without confusing them.

Prepare a focused configuration inquiry

Bring the required coordinate representation, the intended recipient application and the name of the accuracy-evidence owner to the UNITED UAV inquiry channel. Include a redacted delivery specification if one exists. Ask what a UG39 proposal would include and what must be confirmed with a separate integrator or data provider. Judge the resulting scope by its documented responsibilities and evidence, not by how many digits fit in a sample coordinate column.