Performance of extract_points vs rasterio sample
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- performance
Hướng nghiên cứu
Reproduce the comparison using the linked notebook and the Prague DTM, then inspect xvec/accessor.py around lines 1261-1263 where extract_points delegates to sel(method='nearest'). Compare that behavior with rasterio's sample path, and consider the available xarray and rioxarray routes. Done means identifying and documenting a supported approach that materially improves lazy-raster point extraction.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
One of the questions in the recent Earthmover's webinar on xvec was about the performance of extract_points compared to rasterio's sample method. I have never tested this before so wanted to give it a go and for a large lazy-loaded raster (digital terrain model), our extract_points is waaaay slower. See https://notebooksharing.space/view/4459f651d27b2f214f8590c30aba0782f7515d4c16b00dcd3283492f19f8e694#displayOptions=
The DTM is from https://geoportalpraha.cz/en/data-and-services/97d2c9c11aa9478cb21b469b8a4f820e in case you'd like to test the same but any raster should do the trick I assume.
Under the hood, extract_points is simply passing the coordinates to .sel with method='nearest', which should be doing exactly the same as rasterio's sample. https://github.com/xarray-contrib/xvec/blob/66b541bd509b4bcaade0bbeed3dd90b852b602a3/xvec/accessor.py#L1261-L1263
This is not optimal.
We could possibly use sample via rioxarray if the raster is loaded via xarray as it is available through dtm_da.rio._manager.acquire().sample(list(zip(x, y))) but that is relying on a private API of rasterio. I'll open an issue there if there's an appetite to expose sample on the rio accessor.
Outside of relying on rasterio, is there a way of speeding it up using some xarray magic?
- Ngôn ngữ chính
- Python
- Star
- 139
- Fork
- 14
- 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
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. 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 xarray-contrib/xvec
-
CI
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
xarray-contrib/xvec#145 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
xarray-contrib/xvec#141 · 2 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
xarray-contrib/xvec#129 · 1 bình luận ·
-
update fixtures in futureĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
xarray-contrib/xvec#113 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
xarray-contrib/xvec#100 ·
Tất cả issue của xarray-contrib/xvec
Issue tương tự
-
correction metadata
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
acl-org/acl-anthology#10104 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug status/needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
prowler-cloud/prowler#12885 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug in GaussianTailProbabilityCalibrator: running_statistics=False still uses a windowed varianceĐang mởbug good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
selimfirat/pysad#107 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug ci-failure high priority
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
vllm-project/vllm-omni#8194 · 1 bình luận ·
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 88/100
Maintainer thường phản hồi trong vòng 1 ngày