In RFC 7946 GeoJSON, the first two position values are longitude and then latitude. A UVH1-related survey-data handover should preserve that convention and show how the receiving application interprets a sample feature. Do not accept a coordinate pair merely because its numbers look familiar. Ask for the declared format, source convention and receiving result before approving any conversion or treating the displayed feature as accepted survey evidence.

Read the pair before judging the map

Imagine a purchasing team receiving a small feature file alongside a visually convincing project map. A reviewer copies a coordinate pair into a separate application, gets an unexpected location and asks whether the aircraft measured the wrong place. That question jumps over an important intermediate step: what did the exported values mean, and what order did the receiving tool expect? The answer may concern file interpretation rather than the original observation.

This is a hypothetical delivery-review problem, not a reported customer incident. Its practical value is that the buyer can resolve the ambiguity without inventing a performance explanation. Keep the received file unchanged, identify the intended convention and ask the processing owner to demonstrate the import. A tidy screenshot should support that account, not replace it.

What the GeoJSON source actually specifies

RFC 7946, sections 3.1.1 and 4, specifies longitude followed by latitude for the first two position elements. It uses WGS 84 geographic coordinates expressed in decimal degrees. Those are format conventions. They do not establish the accuracy of a survey, approve a transformation or show that a particular aircraft produces GeoJSON directly. A supplier claiming RFC 7946 delivery should explain that output separately from its original data representation.

The useful procurement distinction is between a convention and an observation. One tells the recipient how to read a value; the other concerns how that value was obtained. Both may matter to the project, but evidence for one cannot silently stand in for evidence for the other. Put them in separate lines of the acceptance brief so the technical reviewer can answer each question on its own terms.

Ask for a sample that exposes the ambiguity

A good demonstration starts with a non-sensitive feature whose intended general location is known to the reviewer. Avoid a sample selected only because it produces an attractive map. Ask the supplier to identify the two values, explain their meaning in the delivered format and show the receiving application reading the actual file. Preserve the feature identifier so the demonstration can be traced back to the delivered record.

The sample should be deliberately useful for checking order. A reviewer should not have to infer the convention from a basemap or guess which number belongs to which axis. The responsible geospatial specialist can choose suitable example values and explain the expected result. This article does not prescribe a survey control procedure or a numerical acceptance tolerance; those belong to the project's qualified reviewer.

Request evidence from the receiving path that the organization will actually use. An export inspected in one desktop tool may later be imported through a web service, copied into a spreadsheet or passed to a contractor. List those intended steps before the demonstration. Otherwise the team may approve one interpretation and discover that a later handoff silently expects something different.

Make the delivery record specific

The following is an editorial checklist for a buyer-owned handover record. It is not a certification template. Its purpose is to make unanswered questions visible while there is still someone available to resolve them.

• Name the intended file format and the convention the supplier claims to follow.
• Identify the source coordinate representation separately from the delivered representation.
• Record the software and export route used to create the sample.
• Keep a feature identifier and an unchanged copy of the received file.
• Name the receiving application and the person reviewing its interpretation.
• Record any proposed conversion, its owner and the evidence required before acceptance.

These fields should describe the actual delivery rather than a generic company workflow. A template that says only that coordinates are checked leaves the central question unanswered. The reviewer needs to know which convention was checked, on which artifact, using which receiving route. Missing information can remain an explicit open item; it should not be filled with assumptions simply to complete the form.

Keep interpretation separate from conversion

If a reviewer suspects reversed values, the first action should be a question, not an undocumented edit. Ask the producer to identify the original representation and the intended output. A field renamed longitude does not by itself prove that its values were converted correctly. Equally, changing a display setting does not explain what happened in an exported file. The evidence should follow the artifact through the disputed step.

When a correction is authorized, retain the original and identify the revised derivative clearly. Record who approved the change and why. This makes it possible to answer a later question about the delivery without reconstructing an informal conversation. It also prevents two departments from reviewing different versions while believing they have the same accepted file.

Do not use file creation or modification dates as a substitute for this explanation. A date can help organize records, but it does not declare coordinate order. A filename containing a geographic label is similarly insufficient. The supplier should provide a clear representation statement and the reviewer should verify the interpretation of the actual delivered content.

A field lesson without an invented field story

The editorial lesson is straightforward: preserve meaning before repairing appearance. A map that suddenly looks correct after several undocumented changes may be harder to defend than an initially incorrect display with a clear explanation and controlled correction. The buyer benefits from knowing which step resolved the issue and which questions remain outside that correction.

For example, suppose the receiving team demonstrates the expected general placement after the producer corrects an export convention. That result can support acceptance of the interpretation issue. It does not automatically close a separate accuracy requirement, validate feature completeness or establish that every geometry in the full delivery is correct. Keep the scope of each conclusion attached to its evidence.

A useful exception note names the affected files, the question under review, the owner and the release condition. It need not accuse a supplier of poor performance. Its job is to stop an unresolved interpretation question from disappearing into a general approval email. Once resolved, preserve the accepted version and the explanation together.

How this connects to a UVH1 inquiry

The UVH1 product page provides the starting identity for a configuration discussion. It does not, by itself, establish a GeoJSON export feature, a mapping software package, a processing service or a survey accuracy guarantee. Ask which components and responsibilities are actually offered for the proposed workflow. Unknown details should remain requests for configuration information.

Separate aircraft supply from data processing and acceptance. The buyer might already have a geospatial contractor, or might be asking whether a separate service can be quoted. State that arrangement explicitly. A response can then distinguish confirmed product information, optional work and decisions that belong to the buyer's technical reviewer. This is more useful than treating a deliverable requirement as an assumed aircraft feature.

For US and Singapore teams, the immediate common question is the recipient's data contract, not an inferred national demand trend. Identify the receiving organization and its stated requirements. This guide makes no claim about local survey licensing, aviation permission or public-agency acceptance. Obtain the appropriate professional advice for those separate obligations.

Questions worth settling before release

Also agree how the accepted sample relates to the final delivery. A single demonstration can explain the intended convention, but the buyer should ask the reviewer what additional checks are needed across the full set of files. Record that answer without turning this editorial checklist into an automatic approval rule. If the final export uses a different workflow or version, ask whether the earlier demonstration still supports it. The release record should name the actual artifact reviewed, not merely refer to an example that happened to open correctly during an earlier meeting.

Is a screenshot enough? It can illustrate the reviewed result, but the acceptance record should identify the actual file, convention and receiving route. A screenshot alone does not let another reviewer reconstruct the interpretation.

Can we swap the values ourselves? Do not turn a suspected explanation into an unauthorized correction. Ask the producer and responsible reviewer to establish the intended representation, approve any change and retain both the original and accepted derivative.

Does correct order prove correct measurement? No. Coordinate interpretation and measurement quality are separate questions. Close each against the evidence and acceptance criteria assigned to it.

Bring one feature and one clear question

Source note: RFC 7946 was published in August 2016 and checked on 15 October 2026. The acceptance checklist is editorial analysis, not a reported survey case or a product performance claim.

Related delivery questions include what a classified-map confidence score means and why lidar GPS week seconds need date context. Each concerns meaning that must travel with a value. They do not replace the coordinate review, but they can help a procurement team separate different acceptance responsibilities.

Browse the VTOL and fixed-wing drone collection, then bring a non-sensitive sample feature, the source convention and the intended receiving application to the UNITED UAV contact team. Ask which UVH1 configuration details can be confirmed and which processing questions need your geospatial specialist. The desired next step is a reproducible handover discussion, not a guessed explanation for a point on a map.