Lesson 3 — SRIDs and projections

Lesson 1 introduced SRIDs at minimum: the acronym, what 4326 means, and that it’s what the dispatch deck uses. This lesson fills in the picture. We’ll look at what an SRID actually identifies, the difference between geographic and projected systems, why 4326 is the natural default for web mapping, and what the alternatives look like in practice.

It’s the shortest of Module 3’s lessons, and the only one that doesn’t add to the database. By the end you’ll have a clear mental model of coordinate systems, which makes everything in the modules ahead easier to reason about.

What an SRID actually identifies

An SRID — Spatial Reference IDentifier — is a number that names a spatial reference system: a complete specification for how to interpret coordinate values. The specification covers several things at once:

• The datum — which mathematical model of Earth the coordinates are referenced against (the Earth isn’t a perfect sphere; a datum is an approximation, like WGS84 or GDA94).
• The coordinate system — what the numbers measure (degrees of latitude and longitude, or metres east and north of some origin).
• The projection — if any, how the curved surface of Earth is mapped onto a flat plane.

PostGIS keeps a registry of SRIDs in a table called spatial_ref_sys, populated automatically when the extension is enabled. About 3,000 rows ship out of the box, covering nearly every coordinate system you’re likely to encounter.

Activity 1 — Look at the SRID registry

Open psql:

1

bin/rails dbconsole

Then count the rows:

1

SELECT COUNT(*) FROM spatial_ref_sys;

You should see somewhere around 3,000-8,000 (depending on PostGIS version). These are pre-installed by the extension.

Look at the row for SRID 4326:

1
2
3

SELECT srid, auth_name, auth_srid, substring(srtext, 1, 80) AS srtext_preview
FROM spatial_ref_sys
WHERE srid = 4326;

You’ll see something like:

1
2
3

 srid | auth_name | auth_srid |              srtext_preview
------+-----------+-----------+-----------------------------------------------
 4326 | EPSG      |      4326 | GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID...

The auth_name is EPSG. The European Petroleum Survey Group maintains a registry of spatial reference system definitions that the entire GIS world has standardised on. When you see “SRID 4326,” it’s shorthand for “the entry numbered 4326 in the EPSG registry.”

The srtext column is the full Well-Known Text definition of the coordinate system. We’ve truncated it for readability; viewing the full text reveals the datum, the ellipsoid parameters, and so on. You don’t need to read these — software does — but knowing they’re there demystifies what an SRID actually is.

Type \q to exit when you’re done.

Geographic vs projected SRIDs

SRIDs come in two broad categories.

Geographic SRIDs describe systems where coordinates are latitude and longitude, in degrees, on the surface of the Earth model. There’s no flat projection involved. SRID 4326 (WGS84) is the canonical example. Coordinates look like (-33.8688, 151.2093) for Sydney — degrees south of the equator, degrees east of Greenwich.

Projected SRIDs describe systems where coordinates have been mapped from the curved Earth onto a flat plane, with the flat-plane numbers usually in metres east and north of some origin. These are useful when you want distances and areas to come out in real units directly. A point’s coordinates in a projected SRID look like large positive numbers — for example, (335000, 6253000) for Sydney in MGA Zone 56 — that have no obvious meaning until you know the projection’s origin.

A projected SRID is always tied to a specific geographic region, because the mapping from curved to flat introduces distortion. A projection that’s accurate near Sydney is wildly wrong over Perth. Australia uses a system of zones — six MGA zones across the continent — where each zone has its own SRID and is accurate within its strip of longitude.

Why 4326 is the default for web mapping

SRID 4326 wins for web mapping because of a chain of historical and practical decisions:

• GPS reports lat/lng. Every coordinate from a phone, a GPS device, or a vehicle tracker arrives as WGS84 lat/lng, which is SRID 4326.
• GeoJSON specifies lat/lng. The GeoJSON spec says coordinates are in [longitude, latitude] on the WGS84 datum. That’s SRID 4326.
• MapLibre and other web mapping libraries expect lat/lng for source data. They re-project internally to whatever the map’s display projection requires (more on that below), but the data they consume is 4326.
• Tile providers serve maps in Web Mercator (which is SRID 3857 — we’ll meet it shortly), but the relationship between 4326 and 3857 is well-defined and handled automatically by the libraries.

So SRID 4326 is the storage and exchange format for web spatial data. Almost every web-shaped spatial app stores data in 4326, transmits in 4326, and lets the rendering layer re-project as needed. That’s what the dispatch deck does.

A practical SRID cheat sheet

For the rest of the tutorial, knowing four SRIDs is enough:

• 4326 — WGS84 lat/lng, geographic. The dispatch deck’s storage SRID. Everything in the database lives in 4326.
• 3857 — Web Mercator, projected, units in metres. This is the projection web slippy maps render in. You won’t store data in 3857, but you’ll see it referenced in tile contexts and occasionally in queries that compute display-proportional distances. Module 7 visits this when we serve vector tiles.
• 28356 — MGA Zone 56, projected, units in metres. Covers Sydney and the New South Wales/Queensland east coast. Survey-grade work in that region uses this. We don’t, but it’s the kind of SRID a surveying app would reach for.
• 4283 — GDA94 lat/lng. Australia’s local geographic datum, slightly more accurate than WGS84 for Australian positions (because it accounts for Australia’s continental drift relative to the WGS84 reference frame). Worth knowing about if you’re working with Australian government data, but the difference from 4326 is about a metre, which doesn’t matter for our purposes.

You’ll occasionally see other SRIDs in real GIS work. The spatial_ref_sys table has thousands. You don’t need to memorise any of them; just know the four above and that there’s a registry to look up the rest.

Transforming between SRIDs

PostGIS converts between SRIDs with ST_Transform. Given a geometry in one SRID and a target SRID, it returns the re-projected geometry.

1
2
3
4
5
6

SELECT ST_AsText(
  ST_Transform(
    ST_GeomFromText('POINT(151.2093 -33.8688)', 4326),
    3857
  )
);

1
2
3

                 st_astext
--------------------------------------------
 POINT(16833296.0... -4006726.7...)

Same point — Sydney — represented in Web Mercator (SRID 3857) instead of WGS84 lat/lng. The numbers are now metres east and metres south of an origin near 0°N 0°E. Unrecognisable as a geographic coordinate, but mathematically equivalent for any software that knows how to interpret SRID 3857.

ST_Transform is also how you would, for example, convert a 4326 point into a metres-based projected SRID, do metres-domain calculations there, and convert back. We don’t need that for the dispatch deck, because ST_DistanceSphere gives us metres directly without re-projecting. But it’s good to know the technique exists, especially for survey-grade work or unusually accurate distance/area calculations.

Activity 2 — Try a few transformations

In psql, transform Sydney’s location from 4326 to a few other SRIDs:

1
2
3
4
5
6
7
8
9

-- WGS84 to Web Mercator (SRID 3857)
SELECT ST_AsText(
  ST_Transform(ST_GeomFromText('POINT(151.2093 -33.8688)', 4326), 3857)
);

-- WGS84 to MGA Zone 56 (SRID 28356)
SELECT ST_AsText(
  ST_Transform(ST_GeomFromText('POINT(151.2093 -33.8688)', 4326), 28356)
);

For 3857 you should see something starting with around POINT(16833296...). For 28356 you’ll see something considerably smaller — around POINT(335000 6253000). Both are Sydney; both represent the same physical point; both have numbers that look completely different because each SRID’s origin and units are different.

Try transforming a point near Perth to MGA Zone 56:

1
2
3

SELECT ST_AsText(
  ST_Transform(ST_GeomFromText('POINT(115.8575 -31.9523)', 4326), 28356)
);

You’ll get a transformation, but the result will be far outside MGA Zone 56’s intended geographic scope — the coordinate values will be very large. PostGIS does the calculation, but the result wouldn’t be useful for metres-domain work. This is the practical reason projected SRIDs are zone-specific: outside their design area, the math returns numbers that aren’t physically meaningful.

What this means for the dispatch deck

Practically, almost nothing changes. Everything we do stores and queries in SRID 4326. We won’t be transforming, projecting, or working with anything outside that.

The reason this lesson matters anyway is that you’ll occasionally encounter spatial data from other sources — ABS boundaries (which we import in Lesson 4 and which arrive in 4326 because that’s what’s distributed), open data portals, third-party APIs. Most of these now produce GeoJSON, which is 4326 by spec. A few legacy sources still ship Shapefiles or similar in projected SRIDs; for those, an ST_Transform to 4326 at import time is all that’s needed.

The deeper reason is that “4326” stops being a magic number once you’ve read this. It’s the EPSG registry’s identifier for the WGS84 lat/lng coordinate system, which is what the entire web mapping world has standardised on, which is why every gem, library, and tile server expects it.

Where this leaves us

You now know:

• An SRID identifies a complete spatial reference system — datum, coordinate system, and projection (if any).
• The spatial_ref_sys table holds about 3,000 SRIDs that ship with PostGIS, all sourced from the EPSG registry.
• SRIDs split into geographic (lat/lng) and projected (metres-on-a-flat-plane).
• 4326 is the universal default for web mapping because it’s what GPS, GeoJSON, MapLibre, and tile providers all expect.
• ST_Transform converts geometry between SRIDs.

Lesson 4 is the practical payoff for everything we’ve covered so far: we import 360 real polygon boundaries from the Australian Bureau of Statistics into a ServiceArea model. Real spatial data, ready for Module 4 to render.