SWEREF 99 TM, RT 90 and Web Mercator — a practical guide

·By The OrbGIS team

Why data lands in the wrong place, why an area measured on a web map comes out several times too big, and how to choose the right coordinate system for Nordic GIS — with the EPSG codes that actually matter.

Every GIS professional has had the moment. You open a delivered dataset, the map zooms out, and your municipality's water network is sitting in the Atlantic Ocean off the coast of Ghana. Or subtler: everything looks right, but a colleague's layer sits four metres from yours, consistently, everywhere. Or subtler still: nothing looks wrong at all, and the area figure you just published is four times too large.

All three are the same problem. Coordinates are just numbers, and numbers mean nothing until you say which system they belong to. That system — the coordinate reference system, or CRS — is the single most consequential piece of metadata in geodata, and the one most likely to be missing, wrong, or quietly changed on the way to you.

This is a practical guide to the ones that matter in Sweden and the Nordics: what they are, when to use which, and how to recognise each failure by its symptom.

What a CRS actually says#

A coordinate reference system answers three questions, and mixing up which one is wrong is what makes these bugs so hard to chase.

  1. Which model of the Earth? The datum — the reference ellipsoid and how it's anchored to the ground. SWEREF 99 and ETRS89 are one anchoring; WGS 84 is another; RT 90 sits on the Bessel 1841 ellipsoid from the nineteenth century. Get this wrong and everything shifts by a small, stubborn, constant amount.
  2. How is the round Earth flattened? The projection, plus its parameters — central meridian, scale factor, false easting. Get this wrong and things move by kilometres, or hundreds of kilometres.
  3. What are the units? Metres or degrees. Get this wrong and your data leaves the planet.

An EPSG code is a compact name for one specific combination of all three: EPSG:3006 is SWEREF 99 TM and nothing else. That's why professionals quote EPSG codes instead of names — "SWEREF 99" alone is ambiguous across thirteen different projections.

Sweden's three generations#

RT 90 (EPSG:3021 and friends)#

The old national system, in use for most of the twentieth century. EPSG:3021 — RT 90 2.5 gon V — is the one you'll meet: a transverse Mercator on the Bessel 1841 ellipsoid, central meridian at roughly 15°48′E, false easting 1 500 000.

Plenty of archives, old deliveries and legacy municipal systems are still in RT 90, and it will keep turning up for years. It is not wrong to hold data in it. It is very wrong to mislabel it — see below.

SWEREF 99 TM (EPSG:3006)#

The national system today, and the default answer for anything covering Sweden. EPSG:3006 is a transverse Mercator on the SWEREF 99 datum (Sweden's realisation of ETRS89), central meridian 15°E, scale factor 0.9996, false easting 500 000. Lantmäteriet's own products are published in it, and the municipal transition away from RT 90 ran through the 2000s and 2010s.

For a national or regional map, in a database, or in a delivery whose recipient you don't know — use SWEREF 99 TM.

The twelve local SWEREF 99 zones (EPSG:3007–3018)#

SWEREF 99 12 00, SWEREF 99 13 30, and so on up to SWEREF 99 23 15. Each is a narrow transverse Mercator zone with its own central meridian, scale factor 1.0 and false easting 150 000, laid out so that scale distortion stays negligible within the zone — which is exactly what surveying and detailed planning at municipal scale need.

Most Swedish municipalities work in their local zone. That's the right call for cadastral and engineering work, and the wrong call for anything crossing a municipal border. A common, healthy arrangement: work locally, publish nationally in SWEREF 99 TM.

Heads up

Because the twelve zones differ only in their central meridian, a layer tagged with the wrong one lands tens of kilometres east or west — often still on land, still looking like perfectly ordinary data, just quietly in the neighbouring municipality.

And why RT 90 mislabelled as SWEREF 99 TM lands in another country#

Look at the false eastings above: 1 500 000 for RT 90, 500 000 for SWEREF 99 TM. Tell your software that a set of RT 90 coordinates is SWEREF 99 TM and it does exactly as told — placing the data about a million metres too far east. Somewhere over Estonia and Russia, roughly. This is the single most common "my data is in the wrong country" cause in Swedish GIS, and it is a labelling error, not a conversion error.

Converting properly is a solved problem: Lantmäteriet publishes official RT 90 → SWEREF 99 transformation parameters, and GDAL, QGIS and PostGIS all know them. Don't hand-roll a shift from two known points.

WGS 84 is not quite SWEREF 99 — and the gap is growing#

EPSG:4326 — WGS 84 latitude/longitude — is what GPS receivers, phones and GeoJSON speak. It's tempting to treat it as interchangeable with SWEREF 99. It nearly is, and the way it isn't is interesting.

SWEREF 99 is a realisation of ETRS89, which is fixed to the Eurasian tectonic plate: a point on Swedish bedrock keeps the same ETRS89 coordinates year after year, which is precisely what a national reference system must do. WGS 84 tracks the global reference frame instead, so it stays fixed relative to the Earth's centre while Eurasia drifts underneath it at roughly 2.5 cm per year.

The two frames were aligned in 1989. That was over thirty-five years ago, so the divergence is now on the order of a metre, and it grows every year. Irrelevant for a web map of bus stops. Not irrelevant for cadastral boundaries, utility networks or machine control.

Web Mercator, and what it costs#

EPSG:3857 — Web Mercator — is the projection every slippy web map is built on: Google, OpenStreetMap, and effectively every tile scheme on the internet. It won for good engineering reasons. It's conformal, so shapes stay locally correct at any zoom; it maps the world onto a clean power-of-two tile pyramid; and it's the same everywhere, which is what a global tile cache needs.

Two things about it are routinely forgotten.

It exaggerates area, badly, at Nordic latitudes. Mercator's scale factor grows as 1/cos(latitude), and area error is that squared. At Stockholm's 59°N, distances are stretched about 1.9× and areas about 3.8×. At the Arctic Circle it's roughly 2.5× and 6.3×. Greenland-looks-like-Africa is the famous example, but the practical version is a hectare figure in a planning document that is nearly four times too big because someone measured polygons on a Mercator canvas. Any tool that computes areas and distances properly does so on the ellipsoid, not on the screen projection — and if you can't tell which yours does, that's worth ten minutes of checking.

It isn't a surveying system. Web Mercator treats the WGS 84 ellipsoid as a sphere — a deliberate simplification for tile maths, and the reason it has its own EPSG code separate from the "real" Mercator. Nobody surveys in it, nobody archives in it, and it can't represent the poles at all (it stops at about ±85°).

Web Mercator is an excellent display projection for a general web map. It is a poor working projection for Nordic data — and for decades, moving your data into a browser meant accepting it anyway.

Diagnose it by the symptom#

What you seeAlmost always
Data off the coast of West Africa, near 0°, 0°No CRS at all — a missing .prj, or coordinates parsed as zero. That spot is "Null Island".
Data roughly a million metres east — Baltic states, RussiaRT 90 coordinates labelled as SWEREF 99 TM (or the reverse, landing you in the North Sea).
Points rejected outright, or thrown somewhere impossibleProjected metres interpreted as degrees — a CSV whose easting/northing columns were read as lat/lon. Degrees stop at ±180, so values in the hundreds of thousands are simply invalid.
Two layers offset tens of kilometres east–westTwo different SWEREF 99 local zones, or a local zone mixed with SWEREF 99 TM.
An offset of a few metres that no reprojection fixesDatum mismatch — RT 90 shifted to SWEREF 99 without the official parameters, or WGS 84 versus ETRS89 plate drift.
Everything squashed or stretched north–southLatitude and longitude swapped — axis order, the classic WMS/GML trap.
Positions fine, areas and lengths absurdMeasurement performed in Web Mercator instead of on the ellipsoid.

The pattern worth internalising: large errors are projection errors, small persistent errors are datum errors, and total nonsense is a units error.

So which should you use?#

  • Sweden, national or regional → SWEREF 99 TM (3006).
  • A single Swedish municipality, survey-grade work → your local SWEREF 99 zone (30073018).
  • Finland → ETRS-TM35FIN (3067). Norway → ETRS89 / UTM 33N (25833), or 32N (25832) in the south. Denmark → UTM 32N (25832). Germany → UTM 32N in the west, 33N in the east.
  • Pan-European statistics, grids, area comparisons → ETRS89-LAEA Europe (3035). It's equal-area, which is the whole point when you're comparing regions.
  • A public web map with consumer basemaps → Web Mercator (3857) is fine, as long as your measurements aren't computed in it.
  • Data leaving your organisation as GeoJSON → WGS 84 (4326), because the spec says so.

And in every case: state the CRS explicitly, in the file and in the metadata. Half of these problems are not conversion failures. They are someone assuming.

What this means for a web GIS#

Here's where the old trade-off used to bite. Desktop GIS has always let you work in the CRS your organisation actually uses. Web GIS, historically, has not — data went in, Web Mercator came out, and the projection you'd standardised on for good reasons was something you left at the door.

That's the assumption we built OrbGIS against, so it's worth being specific about what the platform does:

  • The source CRS is read from your file and kept. Upload a SWEREF 99 TM GeoPackage and it is stored as SWEREF 99 TM in PostGIS. There is no projection picker in the upload dialog because there is no decision to make — and no silent reprojection to Web Mercator.
  • Each map has its own projection, chosen in Properties: Web Mercator (3857), SWEREF 99 TM (3006), ETRS89-LAEA Europe (3035), ETRS-TM35FIN (3067), UTM 32N (25832) or UTM 33N (25833). Every one of those has the complete support column behind it — native vector tiles, native basemaps, accurate exports — which is exactly why the list is six long rather than sixty.
  • Vector tiles are generated on the map's own grid. When the map's CRS matches the layer's, tiles are produced directly on that national grid — Lantmäteriet's matrix for 3006, the National Land Survey's JHS matrix for 3067, Kartverket's for 25832/25833, Eurostat's GISCO matrix for 3035 — with no client-side reprojection at all. Where a reprojection is genuinely needed, it happens once per tile at load, not on every frame, and the pipeline is tested against PostGIS ground truth to under two pixels of error.
  • Basemaps follow the same rule. Lantmäteriet renders in 3006, Kartverket in 25833, GISCO in 3035. The gallery only offers basemaps compatible with the map's CRS, so you never get a silently warped raster underneath accurate data.
  • Legacy systems keep working. RT 90, the twelve SWEREF 99 local zones, WGS 84, British National Grid and ETRS89 / Poland CS92 all stay registered — maps already saved in them keep rendering correctly. They just aren't offered when you start a new map.
  • CSV imports are checked, not guessed. Coordinate columns are interpreted as WGS 84 lat/lon, with a sanity check that rejects projected metre values instead of cheerfully mapping your municipality to the Gulf of Guinea.
  • The desktop round trip is honest. Add a layer from the QGIS plugin and it arrives in its own CRS — SWEREF 99 in, SWEREF 99 out — edited in QGIS and written straight back.
  • Scale bars mean what they say. The viewer shows live cursor coordinates in DD, DMS, UTM or MGRS with a true ground scale, and print layouts hold an exact scale like 1:25 000 per map frame, with an optional coordinate grid.

Choosing a coordinate system shouldn't be a compromise you make because your software can only do one thing well. It should be a decision you make about your data.

Frequently asked questions#

What is SWEREF 99 TM, and what is its EPSG code?#

SWEREF 99 TM is Sweden's national projected coordinate system: a transverse Mercator with central meridian 15°E, scale factor 0.9996 and false easting 500 000 metres, on the SWEREF 99 datum (Sweden's realisation of ETRS89). Its EPSG code is 3006. It covers the whole country in one zone and is what Lantmäteriet publishes national data in.

What's the difference between SWEREF 99 TM and the SWEREF 99 local zones?#

SWEREF 99 TM (EPSG:3006) is one zone covering all of Sweden, with a small scale distortion that's irrelevant at national and regional scale. The twelve local zones (EPSG:3007–3018, e.g. SWEREF 99 13 30) are narrow zones with scale factor 1.0, designed so distortion is negligible for surveying and detailed planning within a municipality. Use a local zone for cadastral and engineering work, SWEREF 99 TM for anything crossing municipal borders.

Is SWEREF 99 the same as WGS 84?#

Not quite. SWEREF 99 is a realisation of ETRS89, which is fixed to the Eurasian tectonic plate, while WGS 84 follows the global reference frame. The two were aligned in 1989 and have since drifted apart at roughly 2.5 cm per year — about a metre today. Negligible for a general web map, significant for cadastral, utility or machine-control data.

How do I convert RT 90 to SWEREF 99 TM?#

Use the official transformation parameters published by Lantmäteriet — GDAL, QGIS and PostGIS all implement them, so in practice you set the source CRS to EPSG:3021 and the target to EPSG:3006 and let the library do it. Don't derive your own shift from a couple of known points: the difference between the systems includes both a datum change and different projection parameters, and a two-point fit hides the datum error rather than removing it.

Why is my data a million metres off after changing the coordinate system?#

That's the classic RT 90 / SWEREF 99 TM mislabelling. RT 90 2.5 gon V uses a false easting of 1 500 000 metres, SWEREF 99 TM uses 500 000. If the file was tagged as one and actually contains the other, the software shifts it by the difference — around a million metres east or west. The fix is to correct the declared CRS, not to reproject again.

Why are areas wrong when I measure on a web map?#

Because Web Mercator (EPSG:3857) exaggerates area, and the exaggeration grows with latitude: about 3.8× at Stockholm's latitude and 6.3× at the Arctic Circle. If a measurement tool computes on the screen projection instead of on the ellipsoid, every area and distance in northern Europe comes out substantially too large. Measure on the ellipsoid, or work in an equal-area system such as ETRS89-LAEA (EPSG:3035).

Which coordinate system should a web map of Sweden use?#

SWEREF 99 TM (EPSG:3006) if the map is a working tool for Swedish data — it matches Lantmäteriet's basemaps and your own datasets, so nothing has to be reprojected to be drawn. Web Mercator (EPSG:3857) is a reasonable choice for a public map built on consumer basemaps, as long as measurements aren't computed in it.

My data appears off the coast of Africa. What happened?#

You've found Null Island: the point at 0°, 0° in the Gulf of Guinea where coordinates end up when they're missing or parsed as zero. Usually a shapefile delivered without its .prj file, or a CSV where the coordinate columns didn't parse. Fix the declared CRS at the source — reprojecting from a wrong CRS just moves the error somewhere else.

Working in the CRS you actually use#

If your organisation has standardised on SWEREF 99 and your web GIS keeps handing it back as Web Mercator, that's not a law of physics — it's a design decision someone else made. Try OrbGIS free: upload a dataset, set the map to SWEREF 99 TM and see it drawn on Lantmäteriet's own grid. Or get in touch if you'd like to talk through a migration off RT 90 or a local zone.

← All articles

Get new articles by email

One email when we publish something new — nothing else.