Keep a valid coordinate pair from landing in the wrong place

Declare the conventions on both sides

RFC 7946 specifies longitude before latitude and WGS 84 decimal degrees for standard GeoJSON positions. That convention must not be assumed for every spreadsheet, SDK object or upstream geographic file. Record the actual source field order, units, reference system and destination expectation before deciding whether values can be copied. A filename ending in a familiar extension is not sufficient evidence of the exporter’s behavior.

Ask the supplier to identify the coordinate reference system explicitly and provide an independently checkable control location. If the source uses projected coordinates, assigning a geographic label to the same numbers is not a transformation. Leave an undocumented export unresolved and ask a qualified geospatial owner to establish the conversion. Do not experiment with axis swaps until a point merely looks plausible.

Construct fixtures that expose silent interpretation errors

Use a small synthetic or approved public control set with deliberately different longitude and latitude values. Include controls in different parts of the intended coverage area so a single lucky match cannot conceal a wrong assumption. One control should be chosen so that swapping the axes still produces numerically plausible values but visibly changes the intended region. Range checks alone would not detect that case.

Preserve each source pair exactly alongside its expected reference location and destination representation. Add a deliberately reversed pair as a negative fixture, clearly marked as intentionally incorrect. Also include a missing value and a known zero coordinate only where they make sense in the synthetic test. The importer should not silently turn missing information into a real point at the origin.

Compare the transformation and the rendered result separately

Have the technical owner explain where conversion occurs and which component is responsible for it. A source adapter, intermediate export and map library can each make assumptions; two compensating mistakes may make one screen look correct while leaving a downstream export wrong. Trace the same control through those boundaries rather than accepting a screenshot without the underlying values.

At the destination, compare the stored pair and the rendered marker with the independent control. Test an ordinary import and a later update, because a special first-load conversion may not apply to subsequent records. Keep display rounding separate from stored precision. Adding digits to a displayed value does not add evidence about the original location, and a visually precise pin does not establish a verified entrance.

Accept the coordinate contract, not every geographic claim

Write down the source version, destination convention, approved transformation and the controls that passed. Record the permitted tolerance for the intended business task with the qualified owner rather than inventing a universal distance threshold. A regional overview and an on-site arrival map can require different evidence, even when they share the same coordinate file.

Retain the negative fixtures for importer and supplier changes. If a later record is misplaced, distinguish a wrong source location from a correct location interpreted incorrectly; they require different repairs. The acceptance record demonstrates the interchange path under the tested conditions. It does not validate an address, establish property boundaries, authorize a routing decision or permit uploading private customer locations to a mapping service.

Make the reasoning concrete.

A fictional events directory receives a two-column coordinate export for public venues. The source labels the columns latitude and longitude, while the GeoJSON importer expects the opposite order. An early control happens to remain in a broadly plausible region after reversal.

The directory team records an explicit field mapping and reruns the reversed-axis negative fixture. It accepts the tested interchange while leaving entrance accuracy and venue access instructions to their separate verification process.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Source meaning

   What reference system, units and axis order does the supplier actually provide?

2. Destination

   What convention does the receiving format require?

3. Transformation

   Which component and qualified owner are responsible for conversion?

4. Controls

   Which independent locations and deliberately incorrect pairs expose silent errors?

5. Acceptance

   What task-specific tolerance, version and unresolved exceptions are recorded?

Watch for the wrong conclusion.

• Treating an extension or generic latitude/longitude label as a complete contract.
• Relabeling projected numbers without a genuine transformation.
• Accepting a single plausible pin or numeric range check.

Sources & scope

Workflows, fixtures, worksheets and hypothetical examples are original editorial analysis. Sources support the specifically attributed technical claims. No real location data is transmitted, API enabled, account changed or geographic decision implemented.

• RFC 7946: The GeoJSON Format →Primary technical standard · Supports: Sections 3.1.1 and 4 establish standard GeoJSON position order and coordinate reference conventions. Control selection, boundary tracing and acceptance records are original analysis.