UG39 in its approved front-left three-quarter view in a high-ceiling white exhibition space, a distant separate abstract point-cloud display with restrained green and magenta points

UG39 Survey Procurement: Ask What Point-Cloud Classes Actually Mean

A colored point-cloud preview is not a complete classification specification. In a UG39 survey procurement discussion, ask what each class means, how uncertain or excluded records will be handled and who will review the delivered classification. Keep those questions separate from the aircraft configuration. This article provides an editorial buying framework; it does not establish UG39 lidar compatibility, a supplied sensor, processing services or compliance with a survey standard.

What does the green point mean?

A hypothetical supplier opens an impressive point-cloud view during a bid presentation. Some points are green, some are gray and others have another color. A buyer assumes the colors identify classes that can be used in the organization's next workflow. Before making that assumption, ask what controls the display. The preview might be using a class attribute, a source image value or another visualization choice. The purchasing team needs an explanation, not a guess based on appearance.

The important commercial question is whether the proposed delivery contains the distinctions the recipient actually needs. A convincing preview can start a useful conversation, but the contract must describe the agreed information and its limitations. Without that description, two suppliers can appear to offer the same classified deliverable while answering different questions. The difference may only become apparent when someone tries to use the files after the purchasing decision is complete.

For buyers in the United States and South Africa, the framework below is deliberately about scope and evidence. It does not prescribe a national class scheme or replace a qualified geospatial professional's specification. The intended use, applicable project requirements and responsible reviewer must be established for the actual procurement. An official document from one program should not be silently imposed on a different project or jurisdiction.

Use official specifications as bounded examples

The USGS Lidar Base Specification processing requirements explicitly address point classification. They also discuss additional project classes and responsibility for assessing them. This is useful evidence that classification can involve a defined requirement and an assigned review role. It is a USGS lidar program specification, not proof of a universal rule, a supplier's compliance or any capability of UG39.

The editorial procurement lesson is to make the equivalent responsibilities explicit in your own brief, with the appropriate professional's input. Do not copy a class list simply because it is available online. Ask which definitions apply to the intended deliverable, why they are needed and how they will be accepted. The buyer should understand the contract's scope even when specialist judgment is required to write and review the technical details.

Build a class dictionary before the comparison table

Request a draft dictionary with a name and a plain-language meaning for every proposed class relevant to the project. Include the intended use of each distinction and the person responsible for approving it. This is a suggested procurement record, not a claim that every point-cloud format uses the same dictionary structure. The supplier can propose an appropriate representation, provided the receiving team can understand and apply the agreed meanings.

Ask separately about categories that will not be supplied. A bidder may exclude a distinction because it is outside the requested service or because the available evidence does not support it. Record that answer instead of letting an empty line imply inclusion. When reviewing quotations, a clearly stated exclusion can be easier to manage than a broad promise to classify everything with no explanation of what everything means.

The dictionary should also explain how ambiguous cases will be communicated. Do not assume that every record will fit neatly into the buyer's preferred categories. The appropriate technical treatment belongs with the responsible specialist and governing project specification. The procurement task is to ensure that the limitation has a visible place in the agreement, so unresolved information does not disappear behind a simplified preview or a confident summary sentence.

Distinguish excluded records from missing answers

Ask the producer to explain the difference between records intentionally excluded from a particular deliverable and records whose interpretation remains unresolved. These are different questions for the receiving team. A deliberately excluded category may be consistent with the agreed scope. An unresolved classification may require additional review. The buyer should not have to infer which situation applies by noticing that something is absent from a screenshot.

Use the project's own agreed terminology when recording these distinctions. Terms such as unclassified or withheld can carry specific meanings within a technical specification. This article does not assign them universal definitions or recommend a coding procedure. Instead, it recommends asking the supplier and reviewer to state how the applicable terms are being used in the proposed work and where the recipient will find that explanation.

A small example can make the discussion concrete. Ask the supplier to show how one representative ambiguous area would be described in a handover record. The example can be illustrative if no project data is available, but it must be labeled accordingly. It should reveal the reasoning and responsibility structure without pretending to demonstrate the quality of a survey that has not yet occurred.

UG39 in an illustrative science museum forecourt with separate layered terrain panels
Generated product-reference scene, not evidence of lidar installation, a classified survey delivery or a completed customer project.

Ask what the review will establish

A classification review should have a stated purpose in the commercial scope. Ask what the reviewer is expected to determine, which evidence will be available and how unresolved findings will be reported. Do not write a technical acceptance threshold without competent input. Equally, do not accept the word checked as a substitute for a description of the review that the supplier is actually offering.

Separate producer review from buyer acceptance where the project needs that distinction. One party may inspect its own work before delivery while another makes the final decision about fitness for the intended use. Those roles need not be adversarial. A clear responsibility table simply prevents a proposal from implying that an independent acceptance service is included when the quoted activity is an internal production check.

For each review stage, ask for the expected output: a findings list, a clarification record, a revised deliverable or another agreed document. Name the person authorized to close unresolved questions. This provides a commercial path for issues without dictating the producer's entire technical method. It also makes clear that acceptance is a decision with an owner, not an automatic consequence of opening a colorful viewer.

Keep downstream products in view

Explain what the organization intends to do with the classified information. The purpose might involve a subsequent terrain deliverable, an internal comparison or another professionally specified analysis. These are examples of possible requests, not statements that UG39 supplies those results. The supplier needs enough context to identify whether the proposed classification scope answers the buyer's actual question or leaves another separately contracted task.

Do not let a downstream output conceal the assumptions made upstream. Our UG21 contour-deliverable guide separates a chosen contour interval from evidence about the underlying surface. The same buying discipline applies here: name the output, then ask what information supports it. A preview of the final product does not replace the record of definitions and limitations needed to evaluate that product.

Timing is another independent handover question. The UG25 acquisition-date guide explains why a mosaic's issue date may not answer when each area was observed. A classification contract can likewise identify the relevant source and delivery versions without assuming that one convenient timestamp answers every provenance question. Keep these topics separate enough that each receives an explicit response.

Compare scope, not just presentation quality

Use a simple bid table with entries for the class dictionary, stated exclusions, ambiguity handling, review responsibility and handover format. Let each supplier mark the item included, optional, conditional or unavailable. Add a place for evidence and unanswered questions. This comparison is more useful than rewarding the most visually dramatic point cloud while leaving the actual information contract undefined.

The field-oriented lesson is editorial, not an invented customer story: a preview is a conversation aid, while a dictionary and responsibility record make the handover usable. If the supplier cannot yet answer a question, preserve that uncertainty in the procurement record. The next action might be technical clarification or a separately scoped review. It should not be an internal assumption that silently converts an unknown into a passed requirement.

Where UG39 fits, and what remains unconfirmed

The UG39 product page identifies the aircraft for a configuration inquiry. Keep the proposed aircraft, sensor package, integration work, processing and professional acceptance as separately confirmed scope items. Neither the product-reference illustration nor the USGS source proves that a lidar system is supported or supplied. Do not use this guide as evidence of a tested configuration, certification or included deliverable.

Review the VTOL and fixed-wing drone collection when considering the broader category, then ask for current configuration details against your actual requirement. No payload, endurance, price or service claim is inferred here. The useful product conversation starts with the intended workflow and identifies which questions can be answered now, which require specialist assessment and which belong with another provider.

Request a classification response that can be reviewed

Prepare a draft class dictionary and a short responsibility table before seeking a final quotation. Include the intended use, known exclusions, treatment of unresolved cases and the expected review record. Contact UNITED UAV with that UG39 survey-workflow inquiry and ask for a scoped response. The aim is not to secure a stronger-sounding label. It is to understand exactly what information is proposed, what supports it and who will decide whether it answers the project question.

Previous Next
Leave a comment 0 comments

Please note, comments need to be approved before they are published.