NAR lon/lat datum: documented EPSG:4326 vs measured EPSG:4269
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Bắt đầu với nar_lonlat_crs() và các entry point bị ảnh hưởng nar_point(), nar_lon(), nar_lat() và collect_nar(crs = ...). Kiểm tra StatCan NAR User Guide và bằng chứng round-trip đã được báo cáo cho EPSG:4326/EPSG:4269, sau đó xác nhận datum đã công bố với StatCan. Được xem là hoàn tất khi lựa chọn CRS đã được giải quyết và nar_lonlat_crs() cùng các hàm gọi bị ảnh hưởng phản ánh nhất quán câu trả lời đó.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
| assumed lon/lat CRS | median residual |
|---|---|
| EPSG:4269 | 0.057 m (just NAR's 6-decimal rounding) |
| EPSG:4326 | 0.057 m (identical here — see below) |
| OGC:CRS84 | 1.08 m |
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
- Ngôn ngữ chính
- R
- Star
- 0
- Fork
- 0
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của mountainMath/cangeocode
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
mountainMath/cangeocode#6 · 1 bình luận ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
-
Address normalizationĐang mởenhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
mountainMath/cangeocode#3 · 1 bình luận ·
-
NAR apiĐang mởenhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
mountainMath/cangeocode#2 · 3 bình luận ·
Tất cả issue của mountainMath/cangeocode
Issue tương tự
-
bug key bindings source editor
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
REQ - Positron IDE guidanceCó thể đã có người làm @johannajokio đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
get_procs() @return docs don't match returned columns, and pid column is the row indexCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
posit-dev/connectapi#532 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Huber-group-EMBL/Rarr#302 ·
Maintainer thường phản hồi trong vòng 1 ngày