LaunchDetect

Launch Watch · Evidence study

Published

Test satellite-map axis order with a real NASA GIBS scene

A reproduced WMS 1.1.1 and 1.3.0 test matches NASA GIBS pixels, while a wrong-axis request returns HTTP 200 and a black image.

Three requests returned HTTP 200 and valid 256 × 256 PNGs. Only two returned the intended regional image. The third returned a uniform black square after we changed just the bounding-box order.

This small NASA GIBS test demonstrates a practical failure mode in satellite-map clients: transport success can survive a coordinate error. We requested the same MODIS Terra visualization through WMS 1.1.1 and 1.3.0, compared the actual bytes and decoded pixels, then deliberately supplied the wrong axis order as a negative control.

Start with the intended region

The target was longitude 180°W to 170°W and latitude 25°S to 15°S, using MODIS_Terra_CorrectedReflectance_TrueColor with the date selector 2022-01-15. The requested output was a 256-pixel square PNG. NASA documents both supported WMS versions in its GIBS access guide.

Actual NASA GIBS MODIS Terra true-color regional rendering for the requested date 15 January 2022: textured white and gray cloud cover over dark ocean within the longitude 180 to 170 degrees west, latitude 25 to 15 degrees south request.
NASA GIBS / ESDIS, MODIS Terra Corrected Reflectance True Color. Requested date: 15 January 2022. Requested extent: 180°W–170°W, 25°S–15°S; top edge 15°S. Original 256 × 256 response retained without annotations. This is rendered browse imagery, not a calibrated reflectance array.Open full-size figure

For this EPSG:4326 case, WMS 1.1.1 uses longitude, latitude order in BBOX. WMS 1.3.0 follows the coordinate reference system’s latitude, longitude order. Changing the version therefore requires both the SRS-to-CRS parameter change and the coordinate-order change. The OGC WMS specification is the authority for the protocol; this article tests one concrete GIBS implementation.

Measured results from three NASA GIBS requests, 3 October 2026
RequestCoordinate parameterBBOX, in transmitted orderHTTPPNG bytesDecoded size
WMS 1.1.1SRS=EPSG:4326−180, −25, −170, −15200141,037256 × 256
WMS 1.3.0CRS=EPSG:4326−25, −180, −15, −170200141,037256 × 256
Wrong-axis 1.3.0CRS=EPSG:4326−180, −25, −170, −15200914256 × 256

The positive pair agrees at two levels

Both correct requests returned image/png, 141,037 bytes and the same SHA-256 hash. We then decoded each PNG into RGBA pixels and compared every value. Dimensions and all 262,144 channel values matched: 256 × 256 pixels, each with four channels.

The second comparison is useful even when the file hashes match. It states explicitly what the image-level test covers and remains useful in future runs where metadata or compression might change without altering the rendered pixels. Our current result is exact equality for this retained pair, not a tolerance-based visual resemblance.

Reveal the wrong-axis response and the controlled change

The negative control retains WMS 1.3.0, CRS=EPSG:4326, the layer, date, format and dimensions. Only BBOX changes back to the 1.1.1 ordering. Read as latitude, longitude pairs, the first and third values would be −180° and −170° latitude, outside the valid latitude range.

Uniform opaque black 256 by 256 pixel PNG returned by the wrong-axis control; this is a real server response and not a view of dark ocean.
Actual negative-control output from NASA GIBS, retrieved 3 October 2026. Every RGBA pixel is (0, 0, 0, 255). It returned HTTP 200 and 914 bytes. No geographic scene is inferred from this output.Open full-size figure

A successful HTTP status did not validate the requested geography. Neither did a decodable PNG or the expected width and height. Those checks passed in all three cases. The deliberately invalid latitude values and uniform image expose the failure here.

A short test you can repeat

  1. Write down the intended extent in words. Keep west/east longitude separate from south/north latitude before constructing the request.
  2. Hold the layer, date and output size fixed. A comparison cannot isolate axis handling if other image inputs change at the same time.
  3. Capture status, type and bytes. Preserve the full request and response hash; do not stop at HTTP 200.
  4. Decode and compare pixels. Verify dimensions and pixel values, and inspect the scene. For a production map, also check a recognizable geographic feature or a trusted reference layer.
  5. Exercise one controlled error. Here it was a single BBOX change. Confirm that the test can distinguish the resulting failure from the positive case.

The complete requests are linked below. They are live service requests and could change as processing or service behavior changes; the reported results refer to our 3 October 2026 capture. Download the compact result table.

Keep the software result within its scope

Equal rendered pixels confirm that these two requests produced the same image in this test. They do not independently validate every pixel’s geolocation or establish which physical event is visible. The scene is cloud-dominated at this small output size; we have not claimed a separately verified landmark identification.

The date selector also does not establish an exact acquisition time. We did not retrieve underlying science granule identifiers, timestamps or calibrated reflectances, and we make no eruption-timing claim from this image. The RGB values are display values. Use the underlying science products for a physical measurement.

For a client regression test, retain this useful separation: request semantics, transport checks, decoded-pixel equality and geographic validation are distinct checks. Passing one should not silently mark the others complete.

Imagery acknowledgment: NASA Global Imagery Browse Services (GIBS), part of NASA’s Earth Science Data and Information System (ESDIS). Request comparison and analysis: LaunchDetect.

Sources cited in this article