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

Aperta
  • Qualcosa non va?
#6 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
r
Ambito
backend, data

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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:

CSD mean east (m) mean north (m)
3520005 Toronto −13.7 −3.5
3521005 Mississauga +0.8 +2.6
3519036 Markham +0.8 −0.4
3518013 Oshawa −1.2 +1.6
3506008 Ottawa +1.8 −0.4
2466023 Montréal +0.2 −0.1
4806016 Calgary +2.2 −1.3
5915022 Vancouver +0.1 −0.2

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:

area inside as published best shift (true E / N) inside after shift
Toronto, East York (43.70, −79.30) 0.28 +16.8 m / +4.6 m 0.91
Toronto, west end (43.655, −79.47) 0.19 +14.9 m / +5.0 m 0.82
Vancouver (49.245, −123.10) 0.57 ≈ 0 0.57

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.

Lingua principale
R
Stelle
0
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mountainMath/cangeocode

Tutte le issue di mountainMath/cangeocode

Issue simili

Altre issue su R

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.