What is GIS? Coordinate systems and datums

A Geographic Information System is the combination of data, software, and methods used to capture, store, analyze, and visualize information that is located somewhere. The "somewhere" is what separates GIS from spreadsheets and BI tools. In space GIS, the "somewhere" is everywhere on, above, or around Earth — and the coordinates are almost always derived from satellites.

Most newcomers think of GIS as making maps. Maps are a visualization output; they are not the discipline. The real work of GIS is reasoning about geometric and topological relationships: is this launch detection inside this exclusion zone? How close was the rocket plume to the launch pad? Which countries does the ISS fly over in the next hour? Every one of these is a spatial query, and every spatial query depends on coordinates being correctly defined.

Geographic vs projected coordinates

Coordinates come in two flavors. Geographic coordinates are angles measured from Earth's center — latitude (north/south of the equator) and longitude (east/west of the prime meridian). They live on the curved surface of an ellipsoid. Projected coordinates are the result of flattening the curved Earth onto a 2D plane using a mathematical transformation (a "projection"), and they're measured in linear units — typically meters or feet.

Geographic coordinates are best for storage, communication, and most analysis. Projected coordinates are best for measuring distances and areas, and for displaying on flat screens. Every GIS workflow involves choosing the right one for each step.

WGS84: the default datum for satellite-derived data

A datum is the underlying reference frame: which ellipsoid you're using to model Earth, and where it's anchored. The World Geodetic System 1984 (WGS84) is the datum used by GPS and almost every space-domain dataset. Its EPSG code is 4326 — you'll see this constant everywhere in code:

from pyproj import CRS, Transformer

# WGS84 geographic — lat/lon on the WGS84 ellipsoid
wgs84 = CRS.from_epsg(4326)

# Web Mercator — projected meters, used by web maps (Google, Mapbox)
web_mercator = CRS.from_epsg(3857)

# Convert (lat, lon) → (x, y) in meters
to_meters = Transformer.from_crs(wgs84, web_mercator, always_xy=True)
x, y = to_meters.transform(-80.6, 28.6)  # Kennedy Space Center
print(f"Kennedy in Web Mercator: x={x:.0f} m, y={y:.0f} m")

When a satellite (or LaunchDetect) emits a position, that position is almost always WGS84 unless explicitly stated otherwise. Mixing datums silently is one of the most common — and silent — sources of bugs in space GIS.

Why this matters for thermal launch detection

LaunchDetect's ignition coordinates come from NOAA GOES-18 and GOES-19 imagery. The native imagery is in a fixed-grid coordinate system referenced to the satellite, not lat/lon. To compare a hotspot to a known launch pad — which is what makes a detection geocodable — the fixed-grid pixel must be projected to WGS84 lat/lon. That conversion is where 90% of geolocation errors hide. The math is covered in Week 15.

For now, the takeaway is: every space-GIS workflow has at least one coordinate-system conversion in it. Knowing which datum you're starting in, which one you're ending in, and which one the next consumer expects is the discipline.

The big traps

• Assuming (x, y) means (lon, lat). GIS libraries are split: some pass (lon, lat), some pass (lat, lon). pyproj's always_xy=True argument forces the consistent (lon, lat) order. Set it explicitly every time.
• Treating Web Mercator distances as Earth distances. Web Mercator is fine for display, terrible for measurement. At 60° latitude, a Web Mercator meter is roughly half a real meter. For real distances, use a geodesic calculation (Week 5).
• Ignoring datum entirely. A "lat/lon" position without a datum is almost always WGS84 in modern systems — but a 1980s topographic map may be NAD27, and these differ by tens of meters.

The lab walks you through the smallest possible first space-GIS workflow: parsing the ISS two-line element set, computing the current sub-satellite point, and converting that point between WGS84 lat/lon and Web Mercator meters using pyproj. That's the foundation. Everything in the next 29 weeks builds on this.