Skip to content
← escentmachine field notes

Check Longitude and Latitude Order in GeoJSON

On this page
AI-generated illustration; not taken on location · Schematic array with labeled longitude, latitude and optional altitude elements.
AI-generated illustration; not taken on location · A conceptual position array shows the element order; horizontal coordinates use decimal degrees.AI-generated illustration

GeoJSON positions put longitude first and latitude second. To check a suspicious position, identify those two elements, inspect the document’s syntax and coordinate structure, and compare the interpreted position with documented location evidence. Exchange the first two elements only when that evidence establishes the intended pair.

A range warning can help uncover a possible reversal, but it cannot establish what the producer meant. Some pairs remain plausible in either order. A documented landmark, an expected geographic area or an explicit reference position can supply the missing context.

The examples below are synthetic. Where an example includes a third value, its fixture explicitly defines that value as altitude. The cover illustration follows the same assumption: its “optional altitude” label belongs to a synthetic fixture that defines an optional third value as altitude. Treat that meaning as an assumption of these examples and the illustration, and verify the meaning of additional values in real input against the producer’s documentation.

Read each position in longitude–latitude order

Begin with the position itself. GeoJSON places longitude before latitude, and its horizontal coordinates use decimal degrees. Label the elements explicitly so that a reviewer can see which value is being checked against which expectation.

Array element Read it as Inspection question
Index 0, the first element Longitude Does this match the documented longitude?
Index 1, the second element Latitude Does this match the documented latitude?

For the synthetic position [120,45], the longitude candidate is 120 and the latitude candidate is 45. Those labels describe how to interpret the input; they do not establish that it represents the intended place.

GeoJSON uses World Geodetic System 1984 as its geographic coordinate reference system. Record that context alongside the coordinate order when comparing an input with a reference. Check that the reference is suitable for the comparison before treating a numerical match as confirmation.

Give an additional value an explicit meaning

For this guide’s synthetic three-element fixtures, assume the fixture documentation defines the value at index 2 as altitude. Under that explicit assumption, [120,45,30] contains longitude 120, latitude 45 and altitude 30. The horizontal inspection concerns the first two elements, while the example’s third value remains separate.

For real input, ask what the producer documents about any additional value, including its meaning and units. The decimal-degree convention for horizontal coordinates does not answer those questions.

Also check the handoff between systems: what order does the producer document, and what order does the consuming interface expect? Write down both answers. They can help explain how a mismatch arose and where a confirmed correction belongs.

Separate valid JSON from correct coordinates

Treat inspection as several checks with distinct outcomes. Successful JSON parsing establishes that the input passes the parser’s syntax check. It does not establish that the document has the expected GeoJSON structure, that its positions describe the intended place or that a proposed exchange is justified.

Formatting makes later checks easier. Expand the surrounding object and nested arrays so that you can see where a suspected position belongs. Keep the original input available for comparison, and use formatting to improve readability without deliberately changing values.

Check Question it answers What remains to investigate
JSON syntax Can the input be parsed? Coordinate structure and meaning
GeoJSON structure Does the geometry follow the applicable structure rules? Geographic plausibility and intent
Coordinate ranges Do the horizontal values satisfy documented limits? Whether they describe the intended location
Location comparison Does the interpreted position agree with reliable context? Whether a specific correction is justified

These synthetic coordinate excerpts both use valid JSON syntax:

{"coordinates":[120,45]}
{"coordinates":[45,120]}

Parsing them does not choose between their positions. They are excerpts, so inspect the surrounding geometry before evaluating either as part of a complete GeoJSON document.

Keep diagnostic language specific. “JSON parsed successfully” reports a syntax result. “Location confirmed” requires evidence about the intended place. If the syntax check passes while the location remains unresolved, report both outcomes. This gives the next reviewer a clear starting point without implying that every check has passed.

Use ranges to investigate likely reversals

Obtain the accepted longitude and latitude ranges from the specification or validation contract used by your project. Record the actual constraint, the value checked and the array element that supplied it. A useful warning explains the failed check rather than merely calling the position invalid.

For this synthetic comparison, assume the configured checks accept longitude 120 and latitude 45, but reject latitude 120:

Position Longitude candidate Latitude candidate Result under the example’s checks
[120,45] 120 45 Both candidates pass.
[45,120] 45 120 The latitude candidate fails.

Under those assumptions, the second pair suggests a possible reversal. Exchanging its first two elements produces [120,45], which passes the example’s configured checks.

That result supplies a candidate for investigation. It does not establish intent. Possible explanations to investigate include an incorrect value, an unexpected producer convention or coordinates associated with the wrong record. Check the available evidence before choosing among them.

Describe the warning precisely

An expected diagnostic for this fixture could read:

Input: [45,120]
Finding: latitude candidate 120 failed the configured range check
Candidate for investigation: [120,45]
Decision: retain the input pending location evidence

The expected output is a warning with a proposed candidate. No correction has been confirmed.

Next, compare that candidate with the producer’s documentation and the expected location. If those checks disagree, retain the discrepancy for review. A range result answers whether the values pass particular constraints; the location evidence must establish whether the candidate describes the intended record.

Resolve pairs that fit either order

Compare the synthetic positions [12,48] and [48,12]. Assume the project’s documented range checks accept both candidates. A range-only result then leaves the intended position unresolved.

Candidate Longitude-first reading Range result in this example
[12,48] Longitude 12, latitude 48 Accepted
[48,12] Longitude 48, latitude 12 Accepted

The missing evidence concerns the location. Look for a documented landmark associated with the record, a reliable reference position or an expected geographic area. Confirm how that reference labels longitude and latitude before comparing its values with the input.

For a landmark, verify that the reference describes the same feature as the record under review. For an expected area, ask whether it actually distinguishes the two candidates. If the available context leaves both plausible, keep the result unresolved.

Make the deciding evidence explicit

A synthetic test fixture can define its expected position directly:

{
  "expected_longitude": 12,
  "expected_latitude": 48
}

Against this fixture, [12,48] matches the expectation and [48,12] does not. These fields supply the intended answer for the exercise. A real record needs corresponding evidence from its own documentation or reference context.

Record why the evidence is decisive. A useful review note identifies the reference position or expected area, states how its coordinate order was interpreted and explains which candidate agrees with it.

Avoid selecting whichever candidate looks more familiar. If no documented evidence distinguishes them, report “both candidates pass the range checks; intent unresolved.” That result tells the next reviewer exactly what information is still needed.

Find the affected position inside the geometry

Before changing values, identify the exact position within the document. Check the applicable geometry structure, then follow its nesting to each position. For an individual geometry, inspection may be direct; for nested geometries, retain the complete path as you descend.

Do not classify an array as a position solely because it contains two or three numbers. Establish its role from the surrounding structure and the applicable geometry rules. If those rules are unavailable, obtain them before designing an automatic traversal or rewrite.

The following paths illustrate reporting across separate synthetic inputs. Each array’s role is explicitly established by its fixture. The three-element fixture uses the altitude assumption introduced earlier.

Path Value Review action
geometry.coordinates [12,48] Compare this position with location evidence.
geometry.coordinates[0][1] [45,120,30] Investigate this nested position and retain its third value.
properties.display_values [45,120] Leave this fixture’s unrelated application array unchanged.

For a document containing several geometries, include enough of the container path to identify which geometry owns the position. A warning that says only “coordinates are reversed” gives a reviewer too little information to make a controlled correction.

A proposed diagnostic record can capture the observation without modifying it:

{
  "path": "geometry.coordinates[0][1]",
  "observed_position": [45,120,30],
  "longitude_candidate": 45,
  "latitude_candidate": 120,
  "status": "needs_review"
}

These diagnostic field names are workflow examples. Include the failed constraint or unresolved comparison in the accompanying explanation.

After locating one suspicious position, inspect the other verified positions. Determine which have independent evidence of a mismatch and which already agree with their documented expectations.

Make a confirmed correction and inspect the result

Make a correction when the intended location is established. For this synthetic fixture, suppose its reference explicitly identifies longitude 120 and latitude 45, while the observed position is [45,120,30]. The fixture also explicitly defines its third value as altitude. The confirmed change exchanges the first two elements and preserves that third value.

Item Value
Original position [45,120,30]
Documented horizontal expectation Longitude 120, latitude 45
Expected corrected position [120,45,30]
Fixture-defined altitude, preserved 30

For this isolated three-element fixture, the following Python example makes the input and expected result visible:

original = [45, 120, 30]
corrected = [original[1], original[0], original[2]]

print(original)
print(corrected)

Expected output:

[45, 120, 30]
[120, 45, 30]

The example assumes that the array’s role and intended horizontal position have already been confirmed. For a corresponding two-element fixture, the explicit before-and-after pair would be [45,120] and [120,45]; there is no third value to preserve.

Apply the reviewed change at the identified coordinate path. Preserve the surrounding structure and unrelated arrays, then compare the resulting document with the original to inspect the actual differences.

Keep outcomes distinguishable

Use separate results for different levels of evidence:

Result Evidence Expected action
Range warning A horizontal value fails a documented constraint. Report the path and failed check; investigate intent.
Unresolved intent Both orders pass, or location evidence is insufficient. Retain the input and identify the missing context.
Confirmed correction Location evidence establishes the expected pair. Record the original position, corrected position and reason.

Inspect other positions before deciding whether they need the same exchange. Check for mixed ordering rather than assuming every position shares one mistake. Review each proposed change against the evidence available for it.

Finally, repeat the relevant syntax, structure, range and location checks. Confirm that the corrected pair matches the documented expectation, that any additional value remains as intended and that the recorded differences contain only the reviewed changes.

Previous note
Next note