What is the difference between WGS84 and UTM?

WGS84 (EPSG:4326) is a geographic system in angular degrees of latitude and longitude on an ellipsoid. UTM is a family of 60 projected systems that flatten 6-degree-wide zones into meters using the Transverse Mercator projection. WGS84 stores global position; UTM gives a local metric grid for measurement.

When should I use UTM instead of WGS84?

Reproject to the relevant UTM zone whenever you compute buffers, lengths, areas, slope, viewsheds, or any grid-based raster operation. These need a planar metric CRS so that 1 unit equals 1 metre in every direction; degrees do not behave that way.

Can you measure distance and area in WGS84?

Only with geodesic functions that account for the ellipsoid (for example QGIS measures geodesically by default, and PostGIS geography type computes on the sphere/ellipsoid). Planar measurement directly on EPSG:4326 degrees is wrong, because a degree of longitude shrinks from ~111 km at the equator to ~0 at the poles.

How do I pick the right UTM zone for my project?

Compute zone = floor((longitude + 180) / 6) + 1, then choose the northern variant (EPSG 326xx) for the northern hemisphere or southern (327xx) for the south. For a centroid at 7 deg E, 47 deg N that is zone 32N, EPSG:32632.

WGS84 vs UTM: When to Use Each CRS

Short answer

WGS84 and UTM solve two different problems. WGS84 (EPSG:4326) is a geographic coordinate reference system: it stores positions as latitude and longitude in decimal degrees on the WGS 84 ellipsoid, and it is the lingua franca for GPS, web APIs, and data exchange. UTM is a family of 60 projected CRSs that flatten the globe into 6-degree-wide zones and report coordinates in metres, so distances, areas, and grid-based raster maths behave the way a ruler expects.

The practical rule: exchange and store in WGS84; analyse in the correct UTM zone. If your task involves a buffer distance, a length, an area, a slope raster, or anything where "metres" appears in the requirement, you almost certainly want a projected metric CRS, and for a single-zone study area UTM is the simplest choice.

Need the EPSG code for a zone? See the EPSG codes for WGS 84 / UTM zones reference for the full table — e.g. zone 50N is EPSG:32650, zone 18S is EPSG:32718.

What each system actually is

WGS84 — angular coordinates on an ellipsoid

WGS 84 is a datum (a model of the Earth's shape and an origin) plus a geographic coordinate system expressed in degrees. EPSG:4326 is that geographic CRS. A coordinate like 7.4474, 46.9480 means 7.4474 degrees east, 46.9480 degrees north. Crucially, degrees are not a constant ground distance. One degree of latitude is roughly 111 km everywhere, but one degree of longitude is 111.32 km × cos(latitude): about 111 km at the equator, ~78 km at 45 deg, and 0 km at the pole. That is why a 0.01-degree buffer is an ellipse, not a circle, and why "the points are 0.5 apart" tells you nothing useful without the latitude.

One subtlety that bites people: EPSG:4326 defines axis order as latitude, longitude. GeoJSON (RFC 7946) and most GIS GUIs use longitude, latitude. Mixing the two silently puts data in the wrong hemisphere or in the ocean off West Africa (the 0,0 "null island" symptom is usually an axis or missing-value problem).

UTM — a metric grid per zone

The Universal Transverse Mercator system divides the Earth into 60 longitudinal zones, each 6 degrees wide, numbered 1–60 starting at 180 deg W. Within a zone, coordinates use a Transverse Mercator projection in metres. Each zone has a central meridian; the scale factor at the central meridian is 0.9996 (a deliberate 0.04% reduction so that distortion is balanced across the zone rather than zero at the centre and large at the edges).

Coordinates are reported as easting and northing. To avoid negative eastings, every zone has a false easting of 500,000 m at the central meridian. In the southern hemisphere a false northing of 10,000,000 m is added so northings stay positive. So an easting of 412,000 m means 88 km west of the central meridian; a northing of 5,201,000 m (northern hemisphere) means 5,201 km north of the equator.

The EPSG codes follow a clean pattern: WGS 84 / UTM zone N north = 326 + zone, south = 327 + zone. Zone 32N is 32632; zone 32S is 32732.

Choosing the zone

Given the centroid longitude of your study area:

zone = floor((longitude + 180) / 6) + 1

For longitude 7.4 deg E: floor(187.4 / 6) + 1 = floor(31.23) + 1 = 32. North of the equator, so EPSG:32632 (WGS 84 / UTM zone 32N). For a site near Santiago, Chile at 70.6 deg W, 33.4 deg S: floor(109.4 / 6) + 1 = 19, southern hemisphere, so EPSG:32719.

If your area straddles two zones, you have three options: pick the zone that covers most of the data and accept slightly larger scale error at the far edge; use a custom Transverse Mercator with the central meridian set to your centroid; or move to a national/regional projected grid designed for the country (e.g. a Lambert Conformal Conic, or a national UTM-like grid). UTM's accuracy degrades as you leave its 6-degree window — at the zone boundary the scale factor reaches roughly +0.1% relative to true (about 1.0010 at the equator), which is ~1 m per km. That is negligible for a regional map and very much not negligible for cadastral or engineering survey work.

Worked example: a buffer that was secretly an ellipse

A field team collects 240 sample points with a handheld GPS, exported as samples.gpkg in EPSG:4326. The task: a 250 m exclusion buffer around each point, then total buffered area, for a site near 7.4 deg E, 47 deg N.

Doing this in EPSG:4326 with a planar buffer of "0.00225 degrees" (a rough degree-to-metre guess) produces north–south/east–west asymmetry and wrong areas. The correct workflow:

GDAL / OGR:

# Reproject to UTM zone 32N (metres)
ogr2ogr -t_srs EPSG:32632 samples_32632.gpkg samples.gpkg

# Now a 250 m buffer is genuinely circular and an area in m^2 is meaningful

QGIS Processing: run Reproject layer (native:reprojectlayer) with target EPSG:32632, then Buffer (native:buffer) with distance 250 (metres), then add a field with $area — the result is in m^2 because the layer CRS is now metric.

PostGIS: transform first, then buffer:

SELECT ST_Area(ST_Buffer(ST_Transform(geom, 32632), 250)) AS buf_m2
FROM samples;

If you must stay in 4326, use the geography type so PostGIS measures geodesically:

SELECT ST_Area(ST_Buffer(geom::geography, 250)) AS buf_m2  -- metres on the ellipsoid
FROM samples;

Both give defensible numbers; the planar-degrees version does not.

When WGS84 is the right answer

Storage and exchange. Keep your authoritative copy in EPSG:4326 so any consumer can reproject to whatever they need.
Web maps and APIs. GeoJSON delivery is WGS84 by standard; tile rendering then uses Web Mercator (EPSG:3857) — neither is for measurement.
Wide-area or global datasets spanning many UTM zones, where no single zone is appropriate.
Geodesic measurement. When you genuinely need great-circle distances over thousands of km, measure on the ellipsoid (QGIS geodesic measure, PostGIS geography, or ST_DistanceSphere/ST_Length(geography)), not in any single projected grid.

Common pitfalls and why they happen

Planar buffer/area on degrees. The tool happily multiplies degrees as if they were a flat plane. The number is meaningless because the degree-to-metre ratio changes with latitude. Fix: reproject, or use geodesic/geography functions.
Assigning a CRS instead of reprojecting. "Assign/Define projection" only relabels the existing numbers; "Reproject/Transform" actually recomputes coordinates. Assigning EPSG:32632 to data that is really in degrees lands it near null island. Reproject only when the declared CRS is wrong-but-known; assign only when the CRS is missing but you know the true one.
Wrong zone. Reprojecting data from one country into a neighbouring zone shifts it and inflates scale error. Always derive the zone from the data's own longitude.
Axis-order confusion. Latitude/longitude vs longitude/latitude swaps. Check that your easting is the larger-magnitude horizontal value and that points land where they should.
Vertical units ignored. UTM fixes horizontal units; elevation Z values keep whatever their source uses. Mixing feet elevation with metre horizontals breaks slope and volume maths.

QA before you trust the output

Confirm the declared CRS of every input (gdalsrsinfo, ogrinfo -al -so, or Layer Properties).
After reprojection, spot-check a known control point against a trusted reference (a survey marker, a labelled feature) — coordinates should land within a metre or two.
Verify units explicitly: eastings/northings in the hundreds-of-thousands to millions of metres, not in the tens (degrees).
Re-measure a known distance (e.g. a surveyed baseline) in the projected layer; it should match ground truth to well under 1%.
Record source CRS, processing CRS, output CRS, and any datum transformation in the project metadata so the chain is auditable.

Bathyl perspective

In our terrain and exploration work we keep the master archive in EPSG:4326 and reproject to the project's UTM zone (or a national grid) at the start of any analytical pass, never the other way around. The reprojection step, the chosen zone, and the EPSG code go into the project README so a reviewer can reproduce every metric number without guessing what "the projection" was.

WGS84 vs UTM