NAR lon/lat datum: documented EPSG:4326 vs measured EPSG:4269

Issue

The StatCan NAR User Guide documents BG_LATITUDE/BG_LONGITUDE (and BF_REPPOINT_LATITUDE/_LONGITUDE) as EPSG:4326, but the data behaves as EPSG:4269 (NAD83). nar_lonlat_crs() is currently set to EPSG:4269 on that basis.

Evidence

Using NAR locations with exactly one address (so BG_X/BG_Y and the lon/lat describe the same point), re-deriving the projected coordinate from the lon/lat and comparing against BG_X/BG_Y over ~300k records:

StatCan evidently derived the projected and geographic coordinates without a datum shift between them.

Why it currently doesn't bite

On the dev machine PROJ lacks the NAD83↔WGS84 hgridshift grids, so EPSG:4326 and EPSG:4269 transform identically. On a system with those grids installed the two labels diverge by ~1 m. EPSG:4269 keeps the round-trip exact either way, which is why it was chosen.

Scope: affects nar_point(), nar_lon(), nar_lat() and collect_nar(crs = ...). geom is built from BG_X/BG_Y and is unaffected.

Follow-up

Confirm with StatCan which datum the published lon/lat columns are actually on, and whether the EPSG:4326 label in the User Guide is nominal. Revisit nar_lonlat_crs() once answered.

Reference: NAR User Guide, https://www150.statcan.gc.ca/n1/pub/46-26-0002/462600022026001-eng.htm

Start with nar_lonlat_crs() and the affected nar_point(), nar_lon(), nar_lat(), and collect_nar(crs = ...) entry points. Check the StatCan NAR User Guide and the reported EPSG:4326/EPSG:4269 round-trip evidence, then confirm the published datum with StatCan. Done means the CRS choice is resolved and nar_lonlat_crs() and its affected callers consistently reflect that answer.