Before accepting a slope derivative, establish the relationship between the terrain dataset's horizontal units and elevation units, then record the processing environment and inspect a representative result. For a UG73 project discussion, a familiar legend is not enough. The buyer needs evidence that the analyst interpreted the inputs as intended.

Consider a hypothetical terrain delivery passed between two project teams. One team knows how the elevations are expressed; the receiving team relies on a filename and a familiar coordinate reference label. Processing completes and produces a plausible-looking map. That visual plausibility does not resolve whether the relationship between horizontal distances and elevation values was handled correctly.

Trace the two unit declarations independently

Start with the dataset the analyst will actually process, not a description of an earlier export. Ask where the horizontal coordinate units are declared and where the elevation units are declared. Record both references beside the input revision. If either declaration is missing or ambiguous, leave it as a question for the data owner rather than filling the gap with a customary assumption.

A coordinate reference description and an elevation unit statement serve different purposes in this review. The buyer should ask the analyst to explain what each one establishes and what remains uncertain. This article does not provide a universal conversion recipe. The appropriate treatment depends on the input data, the processing method and the intended output.

Keep unit interpretation separate from other terrain questions. The vertical reference, raster alignment, missing-data treatment and intended use may also matter, but they do not answer the same question. A well-organized acceptance record gives each issue its own place so a completed check in one area is not mistaken for approval of the entire derivative.

Read the processing documentation with its version

The GDAL gdaldem documentation explains the relationship between horizontal and elevation units in slope processing. It describes automatic unit-ratio behavior introduced in GDAL 3.11 under documented metadata conditions, and notes limitations for geographic coordinate systems at high latitudes. The page was reviewed on October 18, 2026. These details make the installed version and actual input metadata relevant; they do not justify assuming that every environment chooses the intended treatment automatically.

Ask the analyst to identify the software version, relevant options and the unit information the process used. A statement that the latest tool was used is difficult to reproduce later and may conceal a different environment from the one described in a planning document. Record the actual environment for the accepted output, not just the software named in the quotation.

Where automatic behavior is relied upon, request evidence that the required input information was present and interpreted as expected. Where an explicit setting is used, ask who selected it and how it was checked. The buyer does not need to invent a processing command to ask these questions. The responsible specialist should explain the choice in terms of the supplied dataset.

Commission a small, reviewable test

Before accepting a full-area derivative, agree a representative test with the analyst. It should be small enough to inspect meaningfully and relevant to the terrain and decisions in the project. Select locations where the reviewer can explain the relationship between the input and output. Do not choose only a visually dramatic area because it makes a persuasive presentation slide.

Have the analyst state what the test is intended to demonstrate. It might check that the declared units and chosen processing treatment produce a result consistent with a separately reviewed example. The project should define the expected evidence and acceptance criteria. This article does not supply numeric thresholds or claim that a single test validates every terrain condition across the delivery.

Retain the test input identity, processing description, inspected locations, reviewer comments and conclusion. If the test reveals an unresolved unit question, pause acceptance of the derivative until the responsible parties resolve it. A successful software run and a non-empty output file are execution results, not substitutes for interpreting the result.

Use a disagreement to improve the specification

Suppose, hypothetically, two analysts produce different slope outputs from what appears to be the same terrain source. Before selecting the more plausible map, compare the actual input revisions, declared units, software versions and processing options. They may not have performed the same operation on the same data. Preserve those differences in the review instead of reducing the issue to a preference for one visualization.

If the elevation unit is unclear, ask the data owner for a supported clarification. Do not infer it from the apparent size of a hill or from what similar projects usually deliver. A visual impression can motivate a question, but it should not become the authoritative metadata. Record the clarification and identify any outputs that need reconsideration because of it.

Once resolved, update the delivery specification and repeat the relevant check on the intended input. Explain whether the correction changes only the processing record or also the produced files. That distinction helps the recipient understand whether a replacement dataset is required and which earlier review remains applicable.

Keep input units separate from output expression

The way a slope result is expressed is another decision. A map legend can tell a reader how to interpret displayed values, but it does not prove that the inputs were treated correctly. A buyer should ask for both the input interpretation and the output definition. Avoid accepting a response about the legend when the unresolved question concerns the elevation units supplied to the calculation.

Similarly, changing colors or class breaks does not resolve a unit discrepancy in the underlying derivative. Presentation and computation should remain distinguishable in the handover. A reviewer may need to inspect the data values as well as the visualization, using a method appropriate to the project's technical scope.

Related deliverables deserve separate decisions. A simplified GIS layer needs an agreed tolerance and permitted use, while file checksums address transfer integrity rather than survey quality. These controls can coexist in the same project. None should be used as a shortcut around the analyst's explanation of the terrain unit relationship.

Make derivative lineage understandable

Include the recipient's intended decision in the review record. A derivative requested for preliminary site screening should not silently become evidence for a different engineering decision. Ask the relevant specialist to define the limits of the reviewed use. The buyer can then communicate those limits to downstream teams without pretending to certify technical suitability independently.

A useful handover meeting can follow one output back to its input. The analyst identifies the source revision, points to both unit declarations, explains the processing treatment and shows the inspected result. The recipient then asks where that explanation is preserved in the delivery. This exercise is more informative than accepting a generic statement that standard settings were used.

If that trace cannot be completed, record the missing evidence and its owner. A delayed clarification is preferable to an invented unit declaration. Once the evidence arrives, attach it to the existing review and identify any processing or acceptance work that must be repeated. Keep the unresolved state visible until the responsible reviewer closes it.

A compact lineage record should identify the accepted input revision, horizontal unit declaration, elevation unit declaration, processing environment and output revision. Link the representative test and its reviewer to that record. The exact format can follow the organization's established system; the important point is that the evidence concerns the files actually delivered.

When the terrain input changes, ask which checks need repeating. A replacement source may contain different metadata even when it covers the same area and uses a similar filename. The reviewer should not automatically carry forward the earlier interpretation. Record the effect of the change and the basis for approving the new derivative.

The editorial lesson is to ask an analyst to explain one inspected result in its declared units before approving the entire raster. This is a buyer-side recommendation, not a reported customer incident or a personal field claim. Its value is in making an otherwise hidden assumption discussable while the scope can still be adjusted.

Ask for a UG73 proposal with explicit data responsibilities

The UG73 product listing establishes the product identity for a configuration conversation. It does not establish that a terrain sensor, processing package, analytical service or particular output accuracy is included. Confirm the actual configuration and service boundaries separately. The VTOL and fixed-wing collection supports broader product discussion without proving suitability for a specific terrain-analysis requirement.

Prepare the intended use of the slope output, the available input data description and the receiving team's review needs. State whether the supplier is expected to deliver an aircraft, collect data, process a derivative or coordinate with a separate analyst. These are different responsibilities and may belong to different parties. Avoid allowing a general application label to stand in for a detailed scope.

Through the project inquiry channel, request a unit declaration and a small analyst-reviewed terrain test before pricing the complete derivative delivery. Ask for missing metadata and unresolved assumptions to be identified explicitly. A useful proposal should tell you who interprets the input, what evidence accompanies the result and who decides that the output is suitable for the stated purpose.