Thử nghiệm ShadeMap dùng LiDAR để tính cả bóng cây
(tedpiotrowski.svbtle.com)- ShadeMap trước nay tính bóng đổ bằng dữ liệu độ cao dựa trên radar dễ kiếm trên toàn cầu, nhưng ở những khu vực nhiều cây cối thì dự đoán ánh nắng trực tiếp có thể sai lệch đáng kể
- LiDAR có thể phản ánh chính xác hơn không chỉ địa hình mà cả độ cao của các đối tượng như cây cối và tòa nhà, nhờ đó cho phép mô phỏng bóng do thảm thực vật theo mùa và theo thời điểm trong ngày
- Nhờ bộ dữ liệu LiDAR công khai của bang Washington, đã có thể thử nghiệm render bao gồm bóng cây trên các khu vực thực tế như Seattle metropolitan area
- Để áp dụng vào dịch vụ thực tế, cần thêm bước chuyển đổi các tệp GeoTIFF cỡ hàng trăm GB sang image tile dùng cho trình duyệt, cùng với các vấn đề về giới hạn bộ nhớ và dung lượng lưu trữ
- Ngay cả việc chuyển đổi Seattle metropolitan area sau 12 giờ cũng mới hoàn thành khoảng một nửa và tile đã vượt 15GB, nên việc cung cấp công khai hiện chỉ giới hạn ở bản demo nhỏ vì chi phí
Vì sao ShadeMap trước đây không có bóng cây
- ShadeMap mô phỏng bóng bằng dữ liệu độ cao, và bộ dữ liệu độ cao dễ kiếm trên toàn cầu là dữ liệu dựa trên radar như SRTM
- Radar hoạt động cả ban đêm và có thể xuyên qua mây, nên vệ tinh có thể thu thập dữ liệu ngoài không gian 24 giờ mỗi ngày
- Trong so sánh render tại Bainbridge Island lúc 7:09 sáng ngày 9 tháng 7, dữ liệu dựa trên radar không phản ánh đầy đủ thảm thực vật nên bị thiếu một phần đáng kể bóng đổ
- Với phần giải thích ban đầu rằng radar chỉ phản xạ từ mặt đất, một người dùng HN đã chỉ ra rằng radar cũng phản xạ từ các bề mặt như thảm thực vật, và sau đó bài viết đã được đính chính
- Việc bộ dữ liệu radar SRTM được trích dẫn là nguồn cho dữ liệu độ cao mặt đất đã dẫn tới giả định đó
- Trong khi đó, LiDAR chính xác hơn nhưng phải được thu thập bằng máy bay hoặc drone và không thể xuyên qua sương mù hay mây
- Việc thu thập tốn nhiều thời gian và chi phí, nên thường các chính quyền địa phương phải gánh chi phí khảo sát
Gánh nặng khi chuyển dữ liệu LiDAR thành tile cho trình duyệt
- Bang Washington cung cấp bộ dữ liệu LiDAR bao phủ một khu vực rộng lớn, và có thể dùng nó để cải thiện mô phỏng bóng cây của ShadeMap
- Dữ liệu gốc ở định dạng GeoTIFF phù hợp với phần mềm GIS truyền thống, nên khá xa với các định dạng như JPG hoặc PNG vốn thuận tiện cho việc tải nhanh trên trình duyệt
- Công việc chuyển đổi là cắt các tệp GeoTIFF cỡ hàng trăm GB, dùng số thực và đơn vị imperial feet, thành các image tile nhỏ, rồi mã hóa giá trị metric meters vào các giá trị pixel đỏ, lục, lam
- Trong quá trình làm, tác giả đã mua ổ cứng 1TB và hỏi ChatGPT cách chuyển đổi
- Với 16GB RAM, rất khó tải các tệp dữ liệu lớn cùng lúc, nên phải viết lại mã chuyển đổi để xử lý theo từng vùng nhỏ thay vì toàn bộ bản đồ
- Chỉ riêng việc chuyển Seattle metropolitan area, sau 12 giờ mới hoàn thành khoảng một nửa, còn các tile tạo ra đã vượt 15GB và vẫn tiếp tục tăng
- Kết quả rất ấn tượng, nhưng chi phí hosting công khai dữ liệu là một gánh nặng, nên hiện tại chỉ cung cấp demo cho một khu vực nhỏ
- Sau bản cập nhật, shademap.app hiện có thể cung cấp dữ liệu LiDAR theo từng khối 1 kilômét vuông cho phần lớn bề mặt Trái Đất
1 bình luận
Ý kiến trên Hacker News
Bản demo cực kỳ đẹp và nhanh. Hiện tôi đang xây một kho/nền tảng quy mô lớn để phân tích bản đồ lịch sử và ảnh chụp trên không (https://pastmaps.com - vẫn còn rất sơ khai nên mong mọi người đừng soi quá gắt), và đang xử lý khá nhiều với pipeline tiling và GeoTIFF
Tương tự, tôi cũng gặp vấn đề khi dùng các tệp GeoTIFF gốc làm nguồn, và đã có thể né được nhu cầu phải tile bằng cách gắn HTTP range request vào các tệp tĩnh tải lên S3 rồi tạo một hook tiling tùy chỉnh trong MapLibre. Cách này đẩy việc tính toán sang phía client, nhưng vẫn chạy khá nhanh ngay cả trên các thiết bị di động cũ
Nếu bạn quan tâm đến hỗ trợ nguồn GeoTIFF trong MapLibre, tôi có thể chia sẻ mã nền tảng hoặc một phần công việc đó dưới dạng mã nguồn mở. Tôi cứ tưởng trên Internet chỉ có mình tôi là kẻ lập dị vọc mấy thứ này thôi :D
Trong trường hợp của tôi, GeoTIFF LiDAR dùng đơn vị feet kiểu Anh với độ chính xác số thực dấu phẩy động 32-bit. Nếu lấy dải độ cao từ mực nước biển đến Everest bằng mét (8848) rồi nhét vào int16 thì có thể đạt độ chính xác 0.2m. Như vậy là đủ cho ShadeMap, nên nếu đổi từ float32 sang int16 thì về lý thuyết có thể giảm một nửa dung lượng lưu trữ trên cloud, và nếu tính cả nén PNG thì còn có thể giảm hơn nữa
https://www.cogeo.org/
OpenLayers có hỗ trợ: https://openlayers.org/en/latest/examples/cog.html
Theo tôi biết thì MapLibre và Leaflet không có hỗ trợ tích hợp sẵn
Tôi rất quan tâm đến lĩnh vực này, và thậm chí đang nghĩ đến việc hỗ trợ tài chính cho một vài dự án. Tôi đã gửi email cho Ted rồi, nhưng cũng muốn nói chuyện với bất kỳ ai đang làm kiểu công việc này. Email của tôi có trong hồ sơ
May là đây vẫn là một ngách đủ hẹp nên tôi không lo hộp thư đến bị nổ tung
Tôi cần tìm hiểu thêm xem chính xác vấn đề nằm ở đâu trong định dạng GeoTIFF. Biết đâu việc dùng chung hạ tầng pipeline chuyển đổi thuần túy giữa hai dự án sẽ hữu ích
Nếu đã có hai người thì có lẽ sẽ còn người khác từng đâm đầu vào cùng một bức tường đó
Giải thích rằng “radar bỏ lỡ rõ ràng 90% bóng đổ vì nó không bao gồm thảm thực vật. Radar chỉ phản xạ từ mặt đất nên các vật thể như cây cối và tòa nhà là không nhìn thấy” có vẻ không đúng
Radar ở một số dải tần nhất định có thể xuyên qua tán lá để quan sát, còn gọi là FOPEN. Còn ở khoảng cách và tốc độ bao phủ cần thiết cho việc lập bản đồ địa hình, tôi không rõ radar có thể xuyên qua các tòa nhà hay không
Shuttle Radar Topography Mission được nhắc đến trong bài có lẽ đã dùng radar băng C hoặc băng X, mà cả hai đều phải cho phản xạ từ thảm thực vật và các tòa nhà
Khi chưa đào sâu thêm, lý do dữ liệu radar không có bóng của thảm thực vật và công trình có thể là 1) độ phân giải dữ liệu radar quá thấp (vài chục mét trở lên), 2) chúng đã bị loại bỏ trong hậu xử lý từ nhiều lượt quét radar với hình học khác nhau, hoặc 3) góc tới thấp của radar khiến ngay từ đầu gần như không tạo ra nhiều bóng
Về chuyện radar lấy mẫu đỉnh cây hay lấy mẫu mặt đất, FAQ giải thích rằng nó không thể xuyên qua các tán thực vật dày. Có thể nó đã đi vào bên trong tán một chút, nhưng nhìn chung là bám gần phần trên của tán
Vấn đề là tín hiệu radar phản xạ từ ngọn cây, từ địa hình, hay là sự kết hợp của cả hai. Nhà trắc địa quan tâm đến địa hình, còn nhà nghiên cứu rừng quan tâm đến chiều cao tán cây
Bước sóng được dùng là 5.6cm, không xuyên qua thảm thực vật tốt, nên ở nơi có thảm thực vật từ trung bình đến dày đặc, nó lập bản đồ gần phần trên của tán cây. Các nghiên cứu so sánh với máy đo cao laser cho thấy có một chút xuyên qua, nhưng không xuống tới mặt đất. Nếu thảm thực vật thưa hoặc rụng lá thì có thể thu được phản xạ từ mặt đất. Vegetation Canopy Lidar, từng được lên kế hoạch như một phần của Earth Observing System, có thể cung cấp khả năng này và cho phép so sánh các bộ dữ liệu thú vị
https://www2.jpl.nasa.gov/srtm/faq.html
Bóng đổ trên địa hình núi thật sự là một vấn đề. Một số bản phát hành có vùng trống, đặc biệt quanh khu vực Himalaya, nơi không có phản xạ radar. Nếu quan tâm thì có khá nhiều bài báo về việc lấp các vùng trống trong dữ liệu SRTM
Nếu GeoTIFF được tiền xử lý, và đã có sẵn một pipeline cung cấp dữ liệu độ cao địa hình cho người dùng, thì có vẻ ta có thể chỉ mã hóa phần chênh lệch giữa LiDAR và radar trong tile, rồi chồng riêng dữ liệu cây lên trên dữ liệu địa hình hiện có. Đối tượng cần mã hóa và độ chính xác cần thiết có lẽ chỉ cần khoảng 4 bit, và vì có nhiều giá trị 0 nên chắc sẽ được nén đi. Đây chỉ là ý tưởng mang tính brainstorming
height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)[mapbox/maptiler]height = (R * 256 + G + B / 256) - 32768[mapzen terrarium]Nếu chỉ cần độ cao trên mực nước biển (0~8848m), thì có thể nhét dữ liệu vào 2 byte mà vẫn giữ độ chính xác 0.13m. Độ chính xác của Mapbox là 0.1m
height = (R * 256 + B) / (256 * 256) * 8848[shademap]Tôi định dùng kiểu mã hóa này. Tôi đã thử nghiệm rồi và nó tiết kiệm không gian. Còn thời gian xử lý thì tôi chưa rõ
Cách mã hóa tốt nhất là đưa độ cao thấp nhất của toàn bộ tile vào header, rồi chỉ lưu giá trị sai phân giữa độ cao thấp nhất của tile và độ cao của từng pixel. Cách này hiệu quả về dung lượng nhất, nhưng phải đưa toàn bộ dữ liệu tile vào bộ nhớ để tìm độ cao thấp nhất, nên kém hiệu quả hơn việc stream và mã hóa từng pixel một
Sẽ rất hữu ích nếu ai đó chỉ cho tôi nên học gì để giỏi khoa học dữ liệu topo
Tôi thích Shademaps. Ước gì sản phẩm của tôi dùng cái này thành công hơn, nhưng Ted và Shademaps rất tuyệt. Việc thêm cây là cực kỳ thực tế. Nhiều khu vực dùng công cụ này là đô thị, nhưng trong những nơi không phải đô thị thì dữ liệu về cây hầu như luôn quan trọng hơn cả tòa nhà hay độ cao. Ontario khá bằng phẳng, và 99% người dùng của tôi ở đó
Nghe như một câu hỏi phỏng vấn cho công ty GIS: “Nếu có dữ liệu radar và LiDAR, và muốn hợp nhất chúng trên một thiết bị bị giới hạn bộ nhớ, bạn sẽ làm thế nào?”
Dịch vụ bản đồ của Pháp đã bắt đầu chụp LiDAR độ phân giải cao cho toàn bộ nước Pháp, và một phần đã có sẵn tại: https://geoservices.ign.fr/lidarhd ở phía dưới
Tôi tò mò không biết liệu bạn có định đưa dữ liệu này vào ứng dụng một ngày nào đó không
Trở ngại chính lúc này là vị hôn thê của tôi đang nghỉ hè (cô ấy là giáo viên) nên chúng tôi ra ngoài khá nhiều, và việc tìm bộ dữ liệu LiDAR trên mạng cũng không dễ
Dữ liệu Washington có vẻ đã có từ khá lâu rồi, nhưng tôi lại không biết nó tồn tại cho tới vài tuần trước
Tôi hy vọng một lúc nào đó sẽ đăng một ASK HN về các bộ dữ liệu LiDAR và crowdsourcing được càng nhiều dữ liệu càng tốt
Dự án rất hay
Sao không host dữ liệu trên một bucket S3 có bật Requester Pays? Khi đó bạn chỉ phải gánh chi phí lưu trữ
Truy cập ẩn danh sẽ không còn khả thi nữa (chia sẻ qua Dropbox cũng vậy), nhưng chi phí sẽ giảm đi đáng kể
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
Vì đây là chỉ đọc nên có lẽ không nhất thiết phải có frontend SQL, và cũng có vài cách để cho SQLite truy cập cơ sở dữ liệu nằm trong bucket S3. Ví dụ: https://github.com/michalc/sqlite-s3-query
Bản demo rất ấn tượng, nhưng phần lớn đầu ra có giá trị thấp. Vì bóng đổ đang được tính từ phần trên của tán cây chứ không phải từ mặt đất. Vì vậy ngay cả trong rừng rậm, nó vẫn trông như có ánh nắng vào lúc sáng sớm
Dù vậy, nó vẫn có thể rất hữu ích cho nhiều mục đích như rìa rừng hay thảm thực vật đô thị. Trong các trường hợp sử dụng đó, tile bản đồ có thể nhỏ hơn rất nhiều, và có lẽ cũng có thể lấy dữ liệu LiDAR khi cần rồi chuyển đổi
Chẳng phải có thể chuyển nó sang cơ sở dữ liệu SQLite rồi cung cấp như một tệp tĩnh với chi phí thấp hơn rất nhiều sao?
https://news.ycombinator.com/item?id=27016630
Range request của HTTP là phép màu cốt lõi ở đây, nhưng phần đó vốn đã là thứ “được giải quyết” rồi
Đây gần như là cách tiếp cận ở mức “tiêu chuẩn ngành” ngày nay, nhưng với nhà phát triển nhỏ như tôi thì nó vẫn có nhược điểm
Thứ nhất, phải vận hành một tile server riêng để nhận yêu cầu tile và nội bộ chuyển chúng thành truy vấn SQL hoặc truy vấn mbtile. Tôi không thích tăng thêm các bộ phận vận hành
Thứ hai, phải xử lý toàn bộ hơn 10TB GeoTIFF và con số này còn đang tăng thành mbtiles, mà chi phí tính toán và thời gian thực tế đều rất lớn
Thứ ba, mbtiles tạo ra cùng lắm chỉ có kích thước tương đương GeoTIFF gốc, còn tệ thì lớn hơn nhiều. Đổi lại bạn có truy vấn nhanh hơn, nhưng chi phí host và truyền dữ liệu sẽ tăng. Nếu quan tâm, có một bài viết giải thích rất rõ về tối ưu nén GeoTIFF: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
Ted chắc cũng có suy nghĩ riêng, nhưng đây là kết luận tôi rút ra sau vài tháng tự đào sâu vào lĩnh vực này
Hay
Nói một chút theo góc nhìn của một người xưa từng làm công nghệ địa không gian, đây là câu chuyện có phần liên quan và có thể hơi nhàm chán: từ những năm 2000, các chính quyền địa phương bắt đầu đặt hàng khảo sát hàng không LiDAR theo đơn vị khu vực hoặc một phần khu vực, và xa hơn nữa là xuất hiện xu hướng công khai dữ liệu số thu được cho công chúng
Từ hơn 10 năm trước, các kỹ sư trong khu vực tư nhân đã thường xuyên nhận các bộ dữ liệu LiDAR quy mô toàn thành phố với số lượng lớn để sử dụng cho các phân tích, bản đồ và bản vẽ quy mô nhỏ
Chính sách chia sẻ dữ liệu của chính quyền địa phương khác nhau rất nhiều tùy nơi và có lẽ bây giờ vẫn vậy, nhưng đôi khi dữ liệu LiDAR được cung cấp dưới dạng nhiều lớp như “địa hình bề mặt”, “công trình”, “tán cây”. Đây là kết quả mà đơn vị vận hành LiDAR ban đầu thu nhận và tính toán ở nhiều tần số khác nhau
Các kỹ thuật viên văn phòng sẽ tìm và thực hiện quy trình điều chỉnh dữ liệu theo yêu cầu. Thông thường họ tạo ra các đầu ra quy mô nhỏ bằng phần mềm thương mại và các quy trình thường lệ, và những dịch vụ được đặt hàng vào thời đó đã bao gồm cả phân tích chiếu nắng/bóng râm và phân tích tầm nhìn, rất giống với nội dung đang được bàn ở đây
Những bước đi ban đầu nhằm đưa LiDAR tán cây vào các công việc ở quy mô khu dân cư nhỏ bắt đầu thấm dần vào khu vực tư nhân, nhưng khi đó vẫn là điều mới mẻ và hiếm gặp. Thật đáng khích lệ khi thấy hiện nay những công việc như vậy đang được thực hiện ở quy mô lớn
Tôi gần như không có kinh nghiệm kiểu “khủng long” nào về việc cung cấp dữ liệu quy mô lớn trên mạng, nhưng việc xử lý các bộ dữ liệu địa không gian thô ở quy mô lớn hơn luôn là bài toán cốt lõi của lĩnh vực này. Cuối cùng, mọi công việc đều quy về việc chuyển dịch hoặc trừu tượng hóa những nguồn dữ liệu đó thành các đầu ra hiệu quả, dễ hiểu và tập trung đúng mục đích
Theo nghĩa đó, động lực thực sự để đưa những đổi mới như thế này vào ứng dụng thực tiễn ở quy mô lớn chính là khía cạnh khoa học máy tính, cụ thể hơn là khoa học dữ liệu