Projections and CRS
Every download ships in WGS84, EPSG:4326. Latitude and longitude, decimal degrees, nothing else at launch.
Why 4326
Because it is the least surprising thing to hand someone whose tooling you cannot see. It opens correctly in every GIS, every web map library, every spreadsheet, and every scripting environment without a projection definition travelling alongside it. In CSV it is just two numeric columns.
A projected national grid such as EPSG:3347 is a better analytical default — equal-area behaviour, metres as units, no reprojection needed to join census geography. If everything you do is Canadian analysis in PostGIS, that is the coordinate system you want to work in.
But it is a worse delivery default. It requires the recipient to know what it is, and a file that arrives in a system nobody recognises gets reprojected by guesswork, which is where the errors start.
So: shipped in 4326, reprojected by you at the point of use. One extra step, taken deliberately, in place of a silent one taken wrongly.
When you must reproject
Before any area or distance calculation. This is not optional and it is the mistake that costs people a report.
EPSG:4326 is a geographic coordinate system, not a projected one. Its unit is the degree. ST_Area on a 4326 geometry returns square degrees, which is not a unit of area on the ground, and the amount of ground a degree covers changes with latitude — a degree of longitude in Windsor is about 30% wider than one in Yellowknife.
-- Wrong. Returns degrees, silently.
SELECT ST_Distance(a.geom, b.geom) FROM addresses a, addresses b;
-- Right. Cast to geography for metres on the sphere.
SELECT ST_Distance(a.geom::geography, b.geom::geography) FROM addresses a, addresses b;
-- Also right, and faster for repeated work: reproject once, then use metres.
ALTER TABLE addresses ADD COLUMN geom_3347 geometry(Point, 3347);
UPDATE addresses SET geom_3347 = ST_Transform(geom, 3347);
CREATE INDEX ON addresses USING GIST (geom_3347);For a handful of measurements, the ::geography cast is simplest. For sustained analytical work, reproject the table once to a projected system and index that.
Which projection to reproject to
| Work | Target |
|---|---|
| National, or joining census geography | EPSG:3347 |
| Within one province | The relevant UTM zone, e.g. EPSG:26910 for most of BC |
| Web map tiles | EPSG:3857, at tile generation only |
| Sharing onward | Leave it in 4326 |
The datum trap
Worth knowing even though it does not bite at launch.
EPSG:4326 is WGS84. Canadian authoritative sources are NAD83 — EPSG:4269 for geographic coordinates, EPSG:3347 projected. They are different datums, currently separated by one to two metres in Canada and diverging, because the North American plate is moving.
Our transformation from source to 4326 happens once, on ingest, with the shift applied. What you receive is genuinely WGS84.
Where it bites is joining our data to something else. If you overlay a provincial NAD83 layer on these addresses without transforming it, everything will be offset by a metre or two, and it will look completely fine. At block-face level that is enough to put an address on the wrong side of a lot line.
Two rules:
State the SRID explicitly. Never let a tool infer it. An SRID of 0 means the projection was lost, not that the data is unprojected.
Check before you overlay. SELECT DISTINCT ST_SRID(geom) on both tables, every time.
Verifying what you loaded
SELECT DISTINCT ST_SRID(geom) FROM addresses;One row, value 4326. Anything else needs investigating before you go further.
Other projections
Not offered at launch. If you need a provincial UTM zone or 3347 delivered directly rather than reprojecting locally, tell us — it is a small piece of work and knowing who wants it decides whether it happens.