NAR building coordinates in the City of Toronto are offset by ~18 m (16.5 m W, 6.5 m S)

Start by reading the NAR database build and metadata paths to find where building geometry and CSD_CODE are handled; those files are not named in the issue. Reproduce the Toronto offset with the supplied DuckDB and R code, then check earlier NAR releases and the Toronto blockface representative points. Done means the offset is verified and its scope and handling are documented, including whether a correction or flag is appropriate.

Summary

In the NAR 2026-06 release, building geometry (BG_X/BG_Y, and equivalently BG_LATITUDE/BG_LONGITUDE) for every address in the City of Toronto (CSD 3520005) is offset by a constant ≈18 m. The points are about 16.5 m too far west and 6.5 m too far south of the true building positions. No other municipality shows a comparable shift.

BG_X/BG_Y and BG_LATITUDE/BG_LONGITUDE agree to within 0.1 m, and our EPSG:4269 → 3347 handling is a pure projection change, so the offset is in the published NAR coordinates rather than introduced by cangeocode's transforms. Since cangeocode returns these coordinates as geocoding results, all Toronto geocodes inherit the shift. That is enough to put points on the neighbouring lot or in the street, and it can assign addresses to the wrong dissemination block where DB boundaries follow lot lines or streets.

Evidence

1. Internal to NAR: building points versus their own blockface representative points. The mean of (building − blockface) should be close to 0 over many addresses, because house-to-street directions point every way. Sample of 30k locations per CSD:

2. OSM building footprints. We counted the share of NAR building points that fall inside an OSM building=* polygon, then searched for the shift that maximises it:

Within 150 m of 43.7018, −79.3030 (Munford Cres / Glen Albert Dr), 25% of the 128 building locations fall inside an OSM footprint as published, and 99% after a +16.5 m E / +6.5 m N shift. For example, 18 Munford Cres is published at −79.30325, 43.70111 and lands on the lot line west of the house.

3. JRC EMC-BUILT (Copernicus, 10 m built-up surface, 2022). For 40k residential building anchors across Toronto, the share of built-up surface under the point rises from 26.1% as published to 45.3% at the best shift of +16.5 m E / +6.5 m N. Fitting each quarter of the city separately (west, east, south, north) gives +16–17 m E / +7 m N. The fitted vector has a gradient under 1 m across the city, so this is a pure translation, not a rotation or scale error.

Spatial extent

We fitted the best shift against EMC-BUILT per grid cell, using at most 300 residential building anchors per cell and a split-half consistency check:

• GTA, 1.5 km cells: 278 of 284 cells whose anchors are mostly in CSD 3520005 have the Toronto vector (16 ± 4 m E, 7 ± 4 m N). None of the 1,179 cells in the surrounding CSDs of Peel, York, Durham, Halton, Hamilton and Simcoe do. The shifted region coincides with the City of Toronto boundary.
• National, 3 km cells, per-CSD coherence over 711 CSDs with at least 4 cells: Toronto is the only CSD where most cells share one shift vector (99% of 78 cells). Some small New Brunswick CSDs show a weak, roughly 6 m eastward tendency (e.g. 1321004, 1332076, 1331065). That is below EMC's resolution and only partially coherent, so we don't consider it actionable for now.

Only the 2026-06 NAR release was checked. It would be worth checking whether earlier releases have the same offset, and reporting it to Statistics Canada.

Reproduction

con <- DBI::dbConnect(duckdb::duckdb(), "<nar>.duckdb", read_only = TRUE)
p <- DBI::dbGetQuery(con, "
  SELECT CSD_CODE csd, x, y, BF_REPPOINT_LONGITUDE bl, BF_REPPOINT_LATITUDE bt FROM (
    SELECT *, row_number() OVER (PARTITION BY CSD_CODE ORDER BY hash(LOC_GUID)) i FROM Locations
    WHERE CSD_CODE IN ('3520005', '3521005', '3519036', '5915022') AND x IS NOT NULL
      AND BF_REPPOINT_LATITUDE IS NOT NULL) WHERE i <= 30000")
ll <- sf::st_coordinates(sf::st_transform(sf::st_as_sf(p, coords = c("x", "y"), crs = 3347), 4269))
p$de <- (ll[, 1] - p$bl) * 111320 * cos(p$bt * pi / 180)
p$dn <- (ll[, 2] - p$bt) * 110574
p <- p[abs(p$de) < 200 & abs(p$dn) < 200, ]
aggregate(cbind(de, dn) ~ csd, p, mean)
#> (rounded)
#>       csd    de   dn
#> 3519036   0.8 -0.4
#> 3520005 -13.7 -3.5   <- Toronto
#> 3521005   0.8  2.6
#> 5915022   0.1 -0.2

Suggested handling

• Apply a correction when building the NAR database: for locations with CSD_CODE == '3520005', translate the building geometry by +16.5 m east, +6.5 m north. Apply it in true east/north metres (in lon/lat, or via a local tangent plane), not along EPSG:3347 axes, which are rotated about 10° at Toronto. Record the correction in the DB metadata and make it optional so users can turn it off.
• Alternatively, or as well, flag affected geocodes, e.g. a geom_note column, so users know these points carry a known offset.
• Check whether blockface representative points (BF_REPPOINT_*) in Toronto have a smaller residual offset. The building − blockface mean of (−13.7, −3.5) against the external estimate of (−16.5, −6.5) suggests blockface points may be off by about 3 m in the same direction.

Found while building a dot-density map, where NAR building points are used to place dwellings, from census 2021 dissemination block counts.