Short answer

UTM (Universal Transverse Mercator) divides the world into 60 north-south zones, each 6° of longitude wide, and projects each zone with its own transverse Mercator so distances and areas in metres stay accurate within that strip. To pick the zone, compute floor((longitude + 180) / 6) + 1; for WGS84 the EPSG code is 32600 + zone in the northern hemisphere and 32700 + zone in the south (so UTM 33N is EPSG:32633, UTM 33S is EPSG:32733). UTM is the right working CRS for most local and regional measurement; the catch is what happens at zone boundaries and when a project straddles two zones.

What UTM actually is

UTM is not one projection — it is 60 separate transverse Mercator projections, one per zone, each optimized for a 6°-wide band. The transverse Mercator wraps a cylinder around a meridian rather than the equator, which keeps distortion small near that meridian and lets it grow outward. By restricting each zone to ±3° of its central meridian, UTM bounds the scale error to roughly 1 part in 2,500 at worst (about 0.04%), which is why it is good for measurement.

Each zone has fixed parameters:

  • Central meridian at the middle of the zone (zone 33 → 15° E).
  • Scale factor 0.9996 at the central meridian. This is deliberately set below 1 so the projection cuts the ellipsoid in two lines about 180 km either side of the central meridian; scale is slightly small in the middle and slightly large at the edges, spreading the error.
  • False easting 500,000 m so easting values stay positive across the zone.
  • False northing 0 in the north and 10,000,000 m in the south (so southern coordinates do not go negative below the equator).

So a coordinate like E 412,300 / N 5,648,900 in UTM 33N means 87,700 m west of the central meridian (500,000 − 412,300) and 5,648,900 m north of the equator.

Finding your zone and EPSG code

The formula:

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

Example: longitude 14.5° E → floor(194.5 / 6) + 1 = floor(32.4) + 1 = 33. Northern hemisphere → EPSG:32633.

For the hemisphere split:

  • Northern: EPSG = 32600 + zone (32601 … 32660).
  • Southern: EPSG = 32700 + zone (32701 … 32760).

These are all WGS84-based. If your data is on a different datum (e.g. ETRS89, NAD83), use the matching UTM definition for that datum, not the WGS84 code, or you will introduce a datum offset. In QGIS, the CRS selector shows the area of use bounding box for each — confirm it actually covers your project before committing.

Set or reproject explicitly rather than relying on auto-detection:

# reproject a layer already in WGS84 lon/lat into UTM 33N
ogr2ogr -t_srs EPSG:32633 sites_utm.gpkg sites_wgs84.gpkg

# tag a raster you know is UTM 33N but has no CRS (assign, do not warp)
gdal_edit.py -a_srs EPSG:32633 dem.tif

In PostGIS:

-- reproject geometry from WGS84 to UTM 33N for metric work
SELECT ST_Transform(ST_SetSRID(geom, 4326), 32633) AS geom_utm FROM sites;

Note the distinction: ST_SetSRID only labels the SRID (use when the SRID is missing but coordinates are already correct); ST_Transform actually reprojects the coordinates.

The zone-boundary problem

Because each zone is its own projection, coordinates are discontinuous at zone edges. A point just east of the 12° E boundary has an easting near 800,000 in zone 32 but near 200,000 in zone 33. Two consequences:

  1. You cannot mix layers from different zones in one analysis. Computing a distance between a zone-32 point and a zone-33 point using raw coordinates gives garbage. Reproject both into a single CRS first.
  2. Projects straddling a boundary force a choice. If a project spans, say, 11°-14° E (zones 32 and 33), you can either:
    • reproject everything into one zone (e.g. all into 33N) and accept that points beyond the 3° half-width carry a little more distortion (still small — UTM tolerates a degree or two of overspill fine for most work), or
    • use a CRS designed for the wider extent: a national grid, a custom transverse Mercator with a central meridian at the project centre, or a Lambert Conformal Conic for E-W elongated areas.

For a survey-grade or large E-W project, a purpose-built CRS beats forcing UTM. For a compact site or a region that fits comfortably in one zone, UTM is ideal.

Worked example: choosing a CRS for a regional study

A geological mapping project covers 12.2° E to 13.4° E, 45° N to 46° N (northern Italy, say). Centre longitude ≈ 12.8° E → zone 33 → EPSG:32633 (UTM 33N). The whole extent sits within ±3° of the 15° E central meridian, so distortion is well bounded. But if national basemaps, cadastre, and clients all use a national grid (e.g. an RDN2008 / Gauss-Boaga or ETRS89-based projection), align to that grid instead so deliverables drop straight into the client's stack. Decide the working CRS by who consumes the output, not just by geography.

UTM vs Web Mercator vs national grids

  • Web Mercator (EPSG:3857) is for tiled basemaps only. Its scale factor is 1/cos(latitude), so at 60° N distances are stretched ~2×. Never measure, buffer, or compute area in 3857.
  • UTM is the general-purpose metric workhorse: conformal, metres, low bounded distortion, globally available.
  • National grids (British National Grid EPSG:27700, ETRS89-LAEA EPSG:3035 for pan-European area work, US State Plane, etc.) are tuned to a country's extent and are usually the right choice when your data and clients already live there. ETRS89-LAEA, for instance, is equal-area and preferred for European statistical/area analysis where UTM's conformality is the wrong property.

Common pitfalls and why they happen

  • Buffering or measuring in EPSG:4326. Degrees are not metres, and a degree of longitude shrinks toward the poles, so a 1,000-"unit" buffer is meaningless. Reproject to UTM first. This happens because GIS tools will silently run the operation in whatever CRS is set.
  • Using the wrong hemisphere code. Tagging southern data as 326xx (north) drops 10,000,000 m of false northing and throws features into the wrong place. Confirm hemisphere from the area of use.
  • WGS84 UTM code on non-WGS84 data. Applying EPSG:32633 to ETRS89 data ignores the datum and introduces a metre-scale offset where the two datums diverge. Match the datum.
  • Mixing zones in one project. The classic "data is offset by hundreds of km" symptom. Standardise on one working CRS.
  • Assigning instead of reprojecting (or vice versa). gdal_edit -a_srs / ST_SetSRID relabels; gdalwarp / ST_Transform recomputes coordinates. Using the wrong one moves data or fails to move it.

Validation checks

  • Reproject a layer to UTM and measure a known baseline (a surveyed distance, a 1 km grid square). It should match the truth to within UTM's ~0.04% scale tolerance.
  • Confirm easting values fall in roughly 100,000-900,000 and northings are sensible for the latitude — wild values signal a wrong CRS or hemisphere.
  • Open the layer over an authoritative basemap of known accuracy; gross misregistration usually means a datum or zone error, not a styling issue.
  • Record source CRS, working CRS, output CRS, and any datum transformation in project notes so the chain is auditable.

Bathyl perspective

We pick the working CRS from the project's extent, the measurement task, and the client's existing stack — UTM by default for compact regional work, a national or custom CRS when geography or deliverables demand it. The projection chain is documented so any later analyst can reproduce a measurement exactly.

Related reading

Sources