A GeoPackage spatial index can be internally consistent while still needing a separate check against the feature table it is meant to describe. For a proposed UG39 survey-data handover, ask whether indexed identifiers and envelopes correspond to the final features, not only whether the index structure passes a diagnostic. Apply that check only where the delivered layer uses the relevant spatial-index extension, and preserve the original package during investigation.

An apparently healthy index is a narrower result than it sounds

Suppose a buyer receives a vector package and a report saying its spatial index passed inspection. A reviewer later notices that a feature found through one method is absent from a location-based result. This is a hypothetical diagnostic situation, not a reported UG39 deployment. Several explanations could exist, and the first report should not be dismissed. The immediate question is what that report tested: the index's internal organization, its relationship to the features, or the recipient's actual query behavior.

Those distinctions belong in the handover brief before delivery. A supplier may quite reasonably run a structural diagnostic and describe the result accurately. The misunderstanding arises when the buyer interprets that result as proof of every feature-to-index relationship. Instead of asking for a generic clean database certificate, identify the layers, geometry columns, extension use, and consistency conditions that matter. A precise question lets the data preparer provide evidence without making a broader claim than the test supports.

Read the two technical responsibilities separately

The SQLite R-tree documentation describes rtreecheck() as a check of R-tree integrity. It is not a general assurance that an application feature table and its index represent the same current records. The OGC GeoPackage specification defines the spatial-index extension and its relationship to feature identifiers and geometry envelopes, including maintenance behavior. An extension-specific consistency review therefore needs evidence beyond a healthy index structure.

Do not turn that distinction into a rule that every GeoPackage must contain an R-tree. First establish whether the relevant extension is present and expected for the delivered layer. If it is absent, decide whether that meets the agreed delivery profile. If it is present, evaluate the obligations that apply to it. This avoids failing a legitimate package for an optional feature the contract never required, while still examining an index that the delivered workflow relies upon.

Anchor the review to the final package

Record the delivered filename, checksum, layer names, geometry columns, and inspection tool versions. A diagnostic from an earlier export is not automatically evidence for the final file. The package may have been edited, repackaged, or replaced afterward. Ask the producer to connect the report to the exact artifact submitted for acceptance. If the final package differs, retain both identities and explain the difference rather than silently treating the earlier check as current.

Work from a protected original and a designated review copy. An inspection workflow should not repair or rebuild the only supplied index before the discrepancy is documented. Rebuilding may be a sensible remediation later, but it changes the evidence and can conceal the original failure mechanism. The buyer's first objective is a reproducible finding. Any corrected deliverable should have its own version, its own report, and a clear relationship to the superseded package.

Compare relationships, not just totals

Matching row counts are helpful but insufficient. An index can have the expected number of entries while referring to the wrong set of identifiers. Ask for a comparison of the feature identifiers that should be indexed and the identifiers actually present. Separate missing entries from entries with no corresponding eligible feature. That distinction tells the producer whether the review found an omission, an orphan, or a misunderstanding about which geometries belong in the indexed population.

Eligibility needs explicit treatment. Null and empty geometries should not be counted as ordinary spatial features simply to force totals to match. State the rules used to classify them and retain the counts in the report. Do not manufacture coordinates or index boxes for absent geometry. A buyer may have a separate requirement concerning incomplete feature records, but that is a data-content issue to report alongside the index relationship, not a reason to falsify the comparison.

Define envelope agreement carefully

For features that require index entries, compare the stored bounds with bounds derived through a suitable geometry-aware method. Specify what constitutes agreement for the implementation being reviewed. SQLite's R-tree documentation explains its floating-point bounding-coordinate representation and outward rounding, so demanding exact decimal equality without considering that representation can produce misleading failures. A reviewer should distinguish a permitted representation difference from an envelope that no longer corresponds to the feature.

A useful finding includes the feature identifier, the geometry-derived bounds, the indexed bounds, the comparison rule, and the result. Avoid a screenshot containing only a red count. The producer needs enough detail to reproduce the issue while the buyer needs a clear statement of its significance. If the inspection tool cannot interpret the geometry reliably, mark that limitation and use an appropriate review method rather than presenting an incomplete calculation as authoritative evidence.

Maintenance checks belong on an expendable copy

A final-state comparison answers whether the delivered package is consistent at inspection time. It does not automatically show that a permitted future edit will maintain that relationship. If the contract includes an editable workflow, consider a separate, controlled exercise on a disposable copy. Define the edit operations, the supported application, and the expected post-edit relationship. This is an acceptance test proposal, not an instruction to alter production data or to run unreviewed database statements.

Keep that exercise separate from the static inspection. An immutable archive may not need an editing demonstration, while a working package may. If an editing test fails, describe the exact application and operation involved rather than claiming every editing path is broken. Conversely, a successful demonstration in one application does not certify all software. The intended recipient environment determines which evidence is relevant to the buyer's actual workflow.

Turn a finding into a bounded correction request

Ask the producer to explain the cause, the affected layers, the correction method, and the verification applied to the replacement. Preserve the original discrepancy report. A corrected index should be checked against the final features again, and any remaining exceptions should be identified explicitly. Avoid accepting a statement that the package was optimized if it does not answer the reported relationship problem. Optimization and correctness are different conclusions, even when one operation happens to affect both.

The buyer should also establish whether the replacement changed only index structures or changed feature content. If feature geometry or attributes changed, other acceptance checks may need to be repeated. Do not assume that a repair is limited because its description sounds technical. Request an artifact comparison appropriate to the scope, then decide which evidence remains applicable. This keeps a small consistency issue from quietly becoming an undocumented revision of the delivered dataset.

Retain the receiving team's sign-off beside the corrected artifact. A supplier's successful rerun and a buyer's acceptance decision are related but different records. The former describes technical evidence; the latter confirms that the evidence satisfies the agreed requirement. Naming both owners helps prevent a corrected file from circulating without a clear acceptance status.

Where the aircraft inquiry fits

The UG39 product listing provides the current identity for a platform discussion. This article does not claim that UG39 creates GeoPackages directly, includes a particular processing application, or guarantees a survey outcome. Treat the export and handover pipeline as a proposed arrangement that needs confirmation. Ask who supplies and supports each step, and whether the requested consistency report is included in the data service or must be commissioned separately.

That separation is especially useful when comparing quotations. One offer may address the aircraft while another includes processing and delivery services. A lower headline price does not reveal whether the same handover obligations are covered. Compare the written responsibilities and evidence requirements alongside the VTOL and fixed-wing collection. Do not fill gaps with assumptions about software compatibility, included training, or customer experience that have not been confirmed for the proposed package.

Keep neighboring quality questions visible

A sound index does not establish that attribute values satisfy a declared domain; the UG32 field-domain validation guide addresses that separate condition. Nor does a structurally valid data file prove that its hosted delivery behaves as intended; the UVH1 cloud-optimized raster handover discussion separates file and serving-path evidence. These checks can share an acceptance register without being collapsed into one ambiguous pass.

The practical buyer lesson is to match each assurance to its actual test. For an indexed vector layer, retain structural integrity, feature correspondence, envelope comparison, and any contracted editing demonstration as distinct findings. This is an editorial quality-control framework, not a claim of firsthand field experience or a substitute for project-specific surveying requirements. It can inform US and Australian procurement conversations while leaving local professional and operational obligations with the responsible specialists.

Before requesting a quotation, prepare a sample delivery specification naming the layers, expected extension use, recipient application, and required discrepancy report. Submit it through the UNITED UAV contact page with your UG39 questions. Ask for a written boundary between platform supply and data-service acceptance. The most useful response identifies who will demonstrate feature-to-index consistency and how the final artifact will be tied to that evidence.