The Problem

NASA Worldview provides an interactive browser for >1000 full‑resolution satellite imagery layers, but the codebase is a large, configuration‑driven front‑end with many colormap and layer definition files. Teams that need to add, modify, or debug a specific layer must navigate hundreds of JSON and XML colormap files and a tightly coupled React/Express front‑end.

What This Does

The repository is an interactive web app (≈2880 files in web/) that renders GIBS imagery via OpenLayers. Key files and their responsibilities:

File / FolderResponsibility
web/js/app.jsInitializes the OpenLayers map, reads layer metadata from config/default/common/config/metadata/layers, and registers UI controls.
web/js/main.jsBootstrap entry that starts the Express server (npm start) and wires API routes for tile requests.
tasks/link-check/index.jsCI task that validates all internal and external links (run via GitHub Actions).
config/default/common/brand.jsonCentral branding config (logo, about page text).
config/default/common/colormaps/ (≈350 XML files)Color‑map definitions used by the layer renderer; each file maps data range → color ramp.
config/default/common/config/metadata/layers/ (≈600 MD files)Human‑readable layer descriptions, projection info, and update cadence.
DockerfileDefines the container build (Node LTS, npm install, npm run build).
package.jsonLists dependencies (React, Express, etc.), npm scripts (build, start, test).
.github/workflows/ci-cd.ymlContinuous integration/run‑tests on every push.
LICENSE.mdProject license (MIT‑style).
package-lock.jsonExact dependency versions for reproducible installs.

The app fetches tile JSON from GIBS, applies the colormap specified in the layer’s metadata, and lets users toggle layers, change time steps, and query values. Custom colormaps or layers are added by placing new XML/MD files under config/default/common/ and referencing them in the layer config.

How It Is Wired

Entry point: web/index.html loads web/js/app.js. That module creates an ol.Map, adds a TileLayer whose source is built from the layer’s url and layerId (read from the metadata files). When a user selects a different layer, app.js fetches the corresponding colormap XML and updates the source’s style function.

Control flow:

  1. User selects a layer → app.js reads config/default/common/config/metadata/layers/<layer>.md.
  2. The layer’s colormap field points to a file in config/default/common/colormaps/.
  3. app.js parses the XML, builds a ol.style.Style with the ramp, and re‑applies it to the source.
  4. Tile requests go through the Express server (main.js) which proxies to GIBS endpoints; caching is handled by the browser/OpenLayers.

Outside‑process touches:

  • The Dockerfile builds a container that runs npm start, exposing port 3000.
  • CI runs npm test (503 test files) and npm run link-check.
  • GitHub Actions workflows (ci-cd.yml, secret-check.yml) enforce code health and secret scanning.

A hub exists in config/default/common/ – all layer and colormap references are resolved relative to that directory, so changing the base path requires updates in every metadata file that references a colormap.

How To Use It

Setup (verbatim from README):

git clone https://github.com/moses-y/worldview.git
cd worldview
npm ci   # installs exact deps from package-lock.json
npm run build   # compiles assets (webpack)
npm start   # launches Express server on http://localhost:3000

Docker (from Dockerfile):

docker build -t worldview .
docker run -p 3000:3000 worldview

Configuration – no environment variables are required; all settings live in config/default/common/. To add a new layer, place its metadata MD file and corresponding colormap XML in the config/default/common/ tree and reference the layer name in app.js’s layer registry.

Running tests:

npm test   # executes the 503 test files (Jest)

Real‑World Use

A flood‑monitoring team can enable the “MODIS Thermal Anomalies” colormap (config/default/common/colormaps/firms/MODIS_All_Thermal_Anomalies.xml) to visualise active fire hotspots in near‑real time. The following snippet shows how a custom client could load the layer via OpenLayers:

import Map from 'ol/Map.js';
import TileLayer from 'ol/layer/Tile.js';
import OSM from 'ol/source/OSM.js'; // replaced by GIBS source

const map = new Map({
  target: 'map',
  layers: [
    new TileLayer({
      source: new XYZ({
        url: 'https://gibs.earthdata.nasa.gov/wms/gibs/tiles/modis/true_color',
        params: { LAYER: 'Modis_Thermal_Anomalies' },
        style: 'colorramp' // loaded from colormap XML
      })
    })
  ],
  view: new View({ center: [0,0], zoom: 2 })
});

Code Health & Issues

  • Tests: 503 test files detected (Jest suite under web/ and tasks/).
  • Documentation: 23 doc files in doc/ (configuration, Docker, embedding, etc.).
  • CI/CD: GitHub Actions workflows present (.github/workflows/ci-cd.yml, secret-check.yml).
  • License: LICENSE.md included.
  • Lockfile: package-lock.json ensures reproducible installs.
  • No structural red flags were found (tests/CI/license/lockfile all present where expected).

SDLC observations: The repo relies on a monolithic config directory; any change to the base path ripples through many layer/colormap references. Test coverage is extensive for link checking and unit logic, but the sheer number of config files can make localized changes tedious.

The Bottom Line

Worldview is a mature, well‑instrumented UI for browsing NASA’s GIBS satellite imagery, backed by a comprehensive colormap/configuration set and solid CI. It’s ideal for teams needing rapid, interactive access to full‑resolution Earth observation data or who want to embed/customize GIBS layers in their own applications. The main trade‑off is the large, flat config surface—adding or modifying layers requires touching many files under config/default/common/, but the existing test and CI guardrails keep regressions in check.