--- title: "WGS84 Is Not an Axis-Order Contract: GeoJSON and WMS Inputs" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/geospatial-ai-geojson-wms-axis-order" last-updated: "2026-10-20" --- # WGS84 Is Not an Axis-Order Contract: GeoJSON and WMS Inputs Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. A WGS84 label and plausible coordinate values do not establish that an input refers to the intended place. Identify the actual interface, version, CRS and tuple convention, then compare the consumer's interpreted point or geographic bounds with the intended location. GeoJSON features and WMS portrayals need their own interpretations; successful parsing or display leaves that comparison unresolved. ## Start with the place the recipient must identify An offer of geographic input for an AI application can look convincing before its location has been established. A file opens, a feature appears and a map has recognizable detail. Those observations leave a separate buyer question: which point or area did the receiving application actually interpret? A GeoJSON feature carries geographic geometry and properties. WMS supplies a map portrayal. Comparing their location conventions does not make those deliverables interchangeable. A map showing the intended area does not establish delivery of the feature geometry an application needs; a feature export does not establish the meaning of a separately supplied map extent. The useful comparison is at the boundary where the recipient consumes each deliverable. A supplier's correct interpretation in its own viewer leaves the downstream interpretation to be established. For an AI input, agreeing on the intended place comes before evaluating what the application does with information associated with that place. References: [G1](https://www.rfc-editor.org/rfc/rfc7946.html), [W1](https://docs.ogc.org/is/06-042/06-042.pdf) ## RFC 7946 GeoJSON declares longitude before latitude RFC 7946, published August 2016, specifies longitude then latitude for the first two position elements. Section 4 uses WGS84 decimal degrees, equivalent to OGC CRS84. Section 5 makes bbox axes follow geometry order: for the two-dimensional region below, west, south, east, north. Section 4 removed the earlier alternate-CRS mechanism but explicitly recognizes alternative coordinate reference systems where all involved parties have a prior arrangement. That qualification needs an actual shared arrangement; a bare WGS84 label does not communicate one. The examples here use the RFC's stated geographic convention. References: [G1](https://www.rfc-editor.org/rfc/rfc7946.html) ## WMS 1.3.0 interprets BBOX through the Layer CRS The named comparison is WMS 1.3.0, OGC 06-042, dated March 15, 2006. Its BBOX order is minimum first axis, minimum second axis, maximum first axis, maximum second axis. In its EPSG:4326 definition, latitude is first. For CRS:84, longitude is first. Both use decimal degrees. The selected CRS must be advertised for the requested layer, directly or through inheritance. These CRS choices are optional; their definitions do not establish that an offered endpoint supports them. Here, x names the first CRS axis rather than universally meaning longitude. Reading minx as west would therefore import an assumption the EPSG:4326 convention does not supply. Keep the version and CRS attached to the tuple. This WMS rule does not determine every other EPSG:4326 API's serialization or every WMS version's behavior. References: [W1](https://docs.ogc.org/is/06-042/06-042.pdf) ## AXIS-01: two plausible positions, two different points All numbers in AXIS-01 are invented, two-dimensional decimal-degree examples. No real city, site or geodetic distance is asserted, and no server or API was tested. The calculations interpret axis positions; they do not reproject coordinates. Under the stated GeoJSON convention, a Point with coordinates [2,48] identifies longitude 2° east and latitude 48° north. The swapped coordinates [48,2] identify longitude 48° east and latitude 2° north. Both are arrays of two numbers, and both pairs fit ordinary longitude and latitude ranges. Shape, syntax and range checks can therefore leave both candidates eligible. They do not tell the buyer which one matches the intended point. If the requirement names the first point, accepting the second because it parses loses the location requirement without necessarily producing a validation error. References: [G1](https://www.rfc-editor.org/rfc/rfc7946.html), [W1](https://docs.ogc.org/is/06-042/06-042.pdf) ## The same region needs differently ordered bounds Now stipulate a separate rectangular regional feature with west = 1° east longitude, east = 3° east longitude, south = 47° north latitude and north = 49° north latitude. The original point at longitude 2°, latitude 48° lies inside it. The swapped point does not. For that regional feature, a GeoJSON bbox is [1,47,3,49]. Its first pair combines west and south; its second combines east and north. This is extent metadata for the regional geometry, not a substitute for the geometry itself. For a WMS 1.3.0 portrayal of the same region using an advertised EPSG:4326 Layer CRS, the BBOX values are 47,1,49,3: south latitude, west longitude, north latitude, east longitude. The changed sequence expresses the same intended bounds under that interface's convention. Interpret the unswapped sequence 1,47,3,49 as that EPSG:4326 BBOX instead. Its latitude runs from 1° to 3° north and its longitude from 47° to 49° east. Minimum values remain below their maxima and all values remain in range, but the tuple describes a different region. The swapped GeoJSON point at longitude 48°, latitude 2° lies inside this other region. This gives the buyer a stronger comparison than a plausible-looking rectangle. Name the intended geographic limits and recover those limits from the delivered tuple's declared interpretation. Matching array length, legal numbers and even an internally consistent point-and-region pair can all survive the same axis mistake. If the layer instead advertises CRS:84, its WMS 1.3.0 BBOX for the stipulated region is 1,47,3,49. That sequence has the correct axis interpretation for that CRS. Seeing the same four numbers elsewhere is therefore neither proof of an error nor a reason to swap them automatically. References: [G1](https://www.rfc-editor.org/rfc/rfc7946.html), [W1](https://docs.ogc.org/is/06-042/06-042.pdf) ## Compare what two offers actually establish Consider two fictional offers for AXIS-01's intended region. Each proposes a regional GeoJSON feature and an accompanying WMS portrayal. These remain separate deliverables with a shared geographic requirement. Offer A says WGS84 and includes a sample that opens successfully. It leaves the GeoJSON convention, the WMS version and Layer CRS, and the receiving application's interpretation unexplained. The sample's successful display leaves unresolved whether the recipient has associated the feature and portrayal with the intended bounds. Offer B identifies RFC 7946 for its feature export and supplies the regional bbox [1,47,3,49]. It identifies WMS 1.3.0 with EPSG:4326 for its portrayal, supplies BBOX values 47,1,49,3 and identifies the layer metadata advertising that CRS. Its proposed comparison evidence names the actual receiving application, its relevant version and interpretation settings, and shows how each delivered extent is interpreted there as west 1°, east 3°, south 47°, north 49°. That last connection matters. Repeating the source numbers establishes less than showing what they mean at the agreed consumer boundary. Evidence from a different viewer or a supplier's intended interpretation cannot silently stand in for the recipient's interpretation. If Offer B supplies only a proposed comparison, that comparison remains outstanding until its result is returned. On this narrow decision, B defines a location claim the buyer can evaluate; A leaves it open. Agreement on bounds still does not establish equivalent feature content, identical raster samples or AI performance. Those remain requirements of the respective deliverables. When the interpretations disagree, have the appointed data or software provider resolve the interface convention. Silently swapping arrays can conceal the disagreement or break a tuple that was already correct for its declared destination. The buyer needs a resolved meaning, not a visually persuasive repair. References: [G1](https://www.rfc-editor.org/rfc/rfc7946.html), [W1](https://docs.ogc.org/is/06-042/06-042.pdf) ## Keep a physical installation inquiry tied to physical work Geographic input interpretation belongs with the appointed data and software providers. If the surrounding storage or compute equipment also needs physical cabling, Leviathan's Structured Cabling & Fiber Installation service is the relevant route for a separately agreed installation. Use the related service and project inquiry to describe a nonconfidential equipment and site outline, approved pathways and endpoints, material responsibilities and the required connection records. That inquiry concerns the physical cabling scope, requirements and availability; it does not offer GIS processing, surveying or model evaluation. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [G1 — RFC 7946: The GeoJSON Format, August 2016, sections 3.1.1, 4 and 5](https://www.rfc-editor.org/rfc/rfc7946.html). Checked 2026-10-20. Defines the GeoJSON position, CRS and bbox conventions used here, including the prior-arrangement qualification. - [W1 — OGC 06-042: Web Map Server Implementation Specification 1.3.0, March 15, 2006](https://docs.ogc.org/is/06-042/06-042.pdf). Checked 2026-10-20. Introduction; sections 6.7.3.2–3, 6.7.4, 7.2.4.6.7, 7.3.3.5–6 and B.3 support the portrayal, axis, BBOX and advertised-CRS distinctions. Describes this historical version. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Describes the physical installation scope relevant to a separate equipment-cabling inquiry. ## Related Leviathan resources - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Discuss a separate physical cabling installation](/contact?service=structured-cabling&from=%2Farticles%2Fgeospatial-ai-geojson-wms-axis-order) - [Remote Hands vs Installation Projects: Compare the Actual Order](/articles/remote-hands-vs-installation-project) - [GPU Site Readiness: Inputs and Owners Before Equipment Arrives](/articles/site-readiness-before-gpus-arrive) - [An INT8 Matrix Operation Still Needs Its Overflow Contract](/articles/gpu-int8-matrix-accumulator-overflow-contract) ## Does the surrounding equipment need physical cabling? Share a nonconfidential equipment, site, approved-endpoint and physical-handoff outline to discuss a separate installation scope, requirements and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/geospatial-ai-geojson-wms-axis-order)