Eksperimen ShadeMap yang menghitung bahkan bayangan pohon dengan LiDAR

• ShadeMap selama ini menghitung bayangan dengan data elevasi berbasis radar yang mudah diperoleh di seluruh dunia, tetapi di wilayah dengan banyak pohon, prediksi sinar matahari langsung bisa meleset besar
• LiDAR dapat merefleksikan ketinggian objek seperti pohon dan bangunan secara lebih presisi selain permukaan tanah, sehingga memungkinkan simulasi bayangan vegetasi menurut musim dan waktu
• Berkat dataset LiDAR publik dari negara bagian Washington, eksperimen rendering yang mencakup bayangan pohon bisa dilakukan di wilayah nyata seperti Seattle metropolitan area
• Untuk penerapan di layanan nyata, ada pekerjaan konversi untuk mengubah GeoTIFF berukuran ratusan GB menjadi tile gambar untuk browser, beserta keterbatasan memori dan masalah kapasitas penyimpanan
• Bahkan konversi Seattle metropolitan area pun setelah 12 jam baru mencapai sekitar setengah jalan, dan tile melampaui 15GB, sehingga penyediaan publik dibatasi pada demo kecil karena beban biaya

---

Alasan ShadeMap sebelumnya tidak memiliki bayangan pohon

• ShadeMap mensimulasikan bayangan menggunakan data elevasi, dan dataset elevasi yang mudah diperoleh secara global adalah data berbasis radar seperti SRTM
• Radar dapat beroperasi pada malam hari dan menembus awan, sehingga satelit bisa mengumpulkan data dari luar angkasa 24 jam sehari
• Dalam perbandingan rendering Bainbridge Island pada 9 Juli pukul 07:09, data berbasis radar tidak cukup merefleksikan vegetasi sehingga sebagian besar bayangan hilang
  • Pada penjelasan awal bahwa radar hanya dipantulkan dari permukaan tanah, seorang pengguna HN menunjukkan bahwa radar juga dipantulkan oleh permukaan seperti vegetasi, lalu koreksi ditambahkan kemudian
  • Karena dataset radar SRTM dikutip sebagai sumber data elevasi permukaan tanah, asumsi seperti itu pun muncul
• Sebaliknya, LiDAR lebih akurat, tetapi harus dikumpulkan dengan pesawat atau drone dan tidak dapat menembus kabut maupun awan
• Pengumpulannya memerlukan banyak waktu dan biaya, sehingga tiap pemerintah daerah harus menanggung biaya survei

Beban mengubah data LiDAR menjadi tile untuk browser

• Negara bagian Washington menyediakan dataset LiDAR yang mencakup wilayah luas, dan ini dapat dimanfaatkan untuk meningkatkan simulasi bayangan pohon di ShadeMap
• Data aslinya berformat GeoTIFF yang ditujukan untuk perangkat lunak GIS tradisional, sehingga kurang cocok dibanding JPG atau PNG yang mudah dimuat cepat di browser
• Proses konversinya memotong file GeoTIFF ratusan GB dengan angka floating-point dan satuan imperial feet menjadi tile gambar kecil, lalu mengenkode nilai metric meters ke nilai piksel merah, hijau, dan biru
• Selama proses tersebut, penulis membeli hard drive 1TB dan melanjutkan pekerjaan sambil bertanya kepada ChatGPT tentang cara konversinya
• Dengan RAM 16GB, file data besar sulit dimuat sekaligus, sehingga kode konversi harus ditulis ulang agar memproses per area kecil, bukan seluruh peta sekaligus
• Bahkan jika hanya mengonversi Seattle metropolitan area, setelah 12 jam pekerjaan baru sekitar setengah selesai, dan tile yang dihasilkan sudah melampaui 15GB serta terus bertambah
• Hasilnya mengesankan, tetapi biaya untuk meng-host data secara publik memberatkan, sehingga untuk saat ini hanya area kecil yang disediakan sebagai demo
• Setelah pembaruan, shademap.app kini dapat menyediakan data LiDAR dalam blok 1 kilometer persegi untuk sebagian besar wilayah Bumi

[GN⁺]

Opini Hacker News

• Demonya sangat keren dan cepat. Saat ini saya sedang banyak berurusan dengan pipeline tiling dan GeoTIFF sambil membangun repositori/platform berskala besar untuk analisis peta lama dan foto udara (https://pastmaps.com - masih sangat awal, jadi mohon jangan dinilai terlalu keras)
  Saya juga mengalami masalah serupa ketika memakai berkas GeoTIFF asli sebagai sumber, lalu bisa menghindari kebutuhan tiling dengan menambahkan HTTP range request ke berkas statis yang diunggah ke S3 dan membuat hook tiling kustom di dalam MapLibre. Memang komputasinya didorong ke klien, tetapi bahkan di perangkat mobile lama pun berjalan cukup cepat
  Kalau tertarik pada dukungan source GeoTIFF di MapLibre, saya bisa membagikan kode dasar atau sebagian pekerjaan itu sebagai open source. Saya kira hanya saya satu-satunya orang aneh di internet yang mengutak-atik hal semacam ini :D

  • Ah, saya tidak terpikir bahwa byte offset bisa dihitung secara langsung. Sebelum ChatGPT muncul, sulit memahami alat pembuat tile dan opsinya, dan materi online juga tidak banyak, jadi menurut saya umumnya lebih baik berbagi secara berlebihan
    Dalam kasus saya, LiDAR GeoTIFF memakai satuan kaki Inggris dengan presisi floating point 32-bit. Jika rentang elevasi dari permukaan laut sampai Everest dinyatakan dalam meter (8848) dan dimasukkan ke int16, kita bisa mendapat presisi 0,2 m. Itu cukup untuk ShadeMap, jadi mengubah float32 menjadi int16 secara teori memangkas ruang penyimpanan cloud menjadi setengah, dan bisa lebih kecil lagi jika memperhitungkan kompresi PNG
  • Kalau Anda “menghindari kebutuhan tiling dengan menambahkan HTTP range request ke berkas statis yang diunggah ke S3”, saya penasaran apakah Anda juga sudah melihat format Cloud Optimized GeoTIFF
    https://www.cogeo.org/
    OpenLayers mendukungnya: https://openlayers.org/en/latest/examples/cog.html
    Setahu saya MapLibre atau Leaflet tidak punya dukungan bawaan
  • https://geoblaze-gsoc.vercel.app dan pustaka-pustaka yang menjadi dasarnya juga layak dilihat. Mereka juga memakai range request untuk GeoTIFF
    Saya sangat tertarik pada bidang ini, termasuk mempertimbangkan untuk mendanai beberapa proyek. Saya sudah mengirim email ke Ted, tetapi saya juga ingin berbicara dengan siapa pun yang mengerjakan hal seperti ini. Email ada di profil saya
    Untungnya ini bidang yang cukup niche, jadi saya tidak khawatir kotak masuk akan meledak
  • Sekarang Anda bukan lagi “orang paling aneh”. Meski begitu, kalian berdua tetap unik. Sepertinya akan bagus jika saling berbagi, bertukar pikiran, dan saling mendukung
    Saya perlu belajar lebih jauh di mana tepatnya masalah pada format GeoTIFF. Mungkin berbagi infrastruktur pipeline transformasi murni di antara dua proyek ini akan membantu
    Kalau ada dua orang, mungkin ada lebih banyak lagi yang menabrak tembok yang sama
  • Saya juga merasa ini benar-benar keren. Saya jadi teringat ketika 8 tahun lalu merombak kode inti penanganan event dan rendering SVG di Leaflet. Senang mengetahui kontribusi open source saya ikut berperan dalam hal-hal keren seperti ini

• Penjelasan bahwa “radar jelas melewatkan 90% bayangan yang muncul karena tidak mencakup vegetasi. Radar hanya memantul dari permukaan tanah, sehingga objek seperti pohon dan bangunan tidak terlihat” rasanya tidak tepat
  Radar pada pita tertentu bisa menembus dedaunan, yang disebut FOPEN. Saya tidak begitu tahu apakah radar bisa menembus bangunan pada jarak dan kecepatan cakupan yang dibutuhkan untuk pemetaan topografi
  Shuttle Radar Topography Mission yang disebut dalam tulisan itu kemungkinan memakai radar C-band atau X-band, dan keduanya semestinya memantul dari vegetasi dan bangunan
  Tanpa menggali lebih jauh, alasan data radar tidak memiliki bayangan vegetasi dan bangunan mungkin karena 1) resolusi data radar terlalu rendah (puluhan meter atau lebih), 2) dihapus saat pascapemrosesan lintasan radar dari beberapa kondisi geometri, atau 3) sejak awal memang tidak banyak bayangan yang terbentuk karena sudut datang radar yang rendah

  • Jika melihat FAQ SRTM, logika tulisan itu terbalik
    Mengenai apakah radar mengambil sampel puncak pohon atau permukaan tanah, FAQ menjelaskan bahwa radar tidak dapat menembus kanopi vegetasi yang tebal. Mungkin saja sedikit masuk ke dalam kanopi, tetapi umumnya mengikuti area dekat bagian atas kanopi
    Masalahnya adalah apakah sinyal radar dipantulkan dari puncak pohon, dari topografi, atau kombinasi keduanya. Ahli geodesi tertarik pada topografi, sedangkan peneliti kehutanan tertarik pada tinggi kanopi
    Panjang gelombang yang digunakan, 5,6 cm, tidak menembus vegetasi dengan baik, sehingga pada vegetasi sedang hingga rapat, yang dipetakan adalah area dekat bagian atas kanopi. Studi yang membandingkannya dengan altimeter laser menunjukkan sedikit penetrasi, tetapi tidak sampai ke tanah. Jika vegetasinya jarang atau tidak berdaun, pantulan dari tanah bisa muncul. Vegetation Canopy Lidar yang direncanakan sebagai bagian dari Earth Observing System dapat menyediakan kemampuan ini dan memungkinkan perbandingan dataset yang menarik
    https://www2.jpl.nasa.gov/srtm/faq.html
  • Tambahan yang bagus. Sepemahaman saya, data SRTM tidak mencakup bangunan atau vegetasi. Mungkin semua selain nilai elevasi terendah difilter keluar. Namun itu bukan sifat “radar” secara umum
  • SRTMv3 mencakup lintang ±60 derajat pada 30 m/piksel. Rilis awalnya 90 m/piksel, dan ada juga rilis yang 30 m di dalam AS serta 90 m di wilayah lain
    Bayangan pegunungan memang masalah nyata. Beberapa rilis memiliki area kosong, terutama di tempat yang tidak memiliki pantulan radar seperti sekitar Himalaya. Jika tertarik, ada cukup banyak makalah tentang pengisian area kosong pada data SRTM

• Jika GeoTIFF dipraproses dan sudah ada pipeline yang menyediakan elevasi medan kepada pengguna, sepertinya tile bisa hanya mengenkode selisih antara LiDAR dan radar, lalu menumpangkan data pohon saja di atas data medan yang sudah ada. Objek yang perlu dienkode dan presisi yang dibutuhkan mungkin muat dalam sekitar 4 bit, dan karena banyak nilai 0, kemungkinan akan hilang lewat kompresi. Ini sekadar ide yang lebih mirip brainstorming

  • Ide bagus. Ada dua cara yang banyak dipakai untuk mengenkode data elevasi ke tile RGB. Keduanya tidak optimal dari sisi rentang nilai karena juga harus memuat elevasi negatif untuk pemetaan topografi dasar laut
    height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1) [mapbox/maptiler]
    height = (R * 256 + G + B / 256) - 32768 [mapzen terrarium]
    Kalau yang dibutuhkan hanya elevasi di atas permukaan laut (0–8848 m), data bisa dimasukkan ke 2 byte sambil mempertahankan presisi 0,13 m. Presisi Mapbox adalah 0,1 m
    height = (R * 256 + B) / (256 * 256) * 8848 [shademap]
    Saya berencana memakai encoding ini. Sudah saya uji dan memang menghemat ruang. Untuk waktu pemrosesan, saya belum tahu
    Encoding terbaik adalah memasukkan elevasi minimum seluruh tile ke header, lalu hanya menyimpan nilai delta antara elevasi minimum tile dan elevasi tiap piksel. Efisiensi ruangnya paling bagus, tetapi untuk menemukan elevasi minimum, seluruh data tile harus dimuat ke memori, dan ini kurang efisien dibanding mengenkode piksel satu per satu secara streaming
  • Saya benar-benar ingin tahu lebih banyak tentang bidang ini. Saya sedang mencari topik berikutnya untuk didalami, dan istilah-istilah di sini tepat bersinggungan dengan posisi pengetahuan yang ingin saya capai
    Akan sangat membantu kalau ada yang memberi tahu apa yang perlu dipelajari agar mahir dalam sains data topologis

• Saya suka Shademaps. Saya berharap produk saya yang memakai ini lebih sukses, tetapi Ted dan Shademaps itu keren. Menambahkan pohon sangat praktis. Banyak area yang memakai alat ini memang perkotaan, tetapi jika tidak, data pohon hampir selalu lebih penting daripada bangunan atau elevasi. Ontario cukup datar, dan 99% pengguna saya ada di sana

  • Dari sisi bisnis dan pemasaran masih agak terseok-seok, tetapi idenya sendiri tampaknya populer, dan pekerjaannya menyenangkan serta memuaskan

• Ini seperti pertanyaan wawancara untuk perusahaan GIS: “Jika Anda punya data radar dan LiDAR, dan ingin menggabungkannya di perangkat dengan memori terbatas, bagaimana caranya?”

  • Dalam beberapa hal, masalah yang dibahas di sini adalah hal-hal yang memang dipersiapkan oleh pendidikan ilmu komputer. Sebelumnya saya mengerjakan pengembangan web, dan hampir tidak pernah perlu khawatir apakah sebuah halaman web akan muat di memori, serta jarang memakai lebih dari beberapa persen siklus yang bisa diberikan prosesor

• Layanan peta Prancis mulai melakukan pemotretan LiDAR HD untuk seluruh Prancis, dan sebagian sudah tersedia: https://geoservices.ign.fr/lidarhd ada di bagian bawah
  Saya penasaran apakah ada rencana untuk memasukkan data ini ke aplikasi suatu hari nanti

  • Tentu. Terima kasih untuk tautannya
    Hambatan utama saat ini adalah tunangan saya sedang libur musim panas (dia guru), jadi kami banyak keluar, dan sulit juga menemukan dataset LiDAR secara online
    Data Washington sepertinya sudah ada cukup lama, tetapi saya tidak tahu keberadaannya sampai beberapa minggu lalu
    Suatu hari nanti saya berharap bisa memposting ASK HN tentang dataset LiDAR dan meng-crowdsource data sebanyak mungkin

• Proyek yang keren
  Bagaimana kalau meng-host data di bucket S3 dengan Requester Pays diaktifkan? Dengan begitu Anda hanya menanggung biaya penyimpanan
  Akses anonim memang jadi tidak mungkin (berbagi lewat Dropbox juga begitu), tetapi biayanya akan turun banyak
  https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
  Karena hanya-baca, sepertinya tidak harus ada frontend SQL, dan ada beberapa cara agar SQLite bisa mengakses database di bucket S3. Contoh: https://github.com/michalc/sqlite-s3-query

• Demonya sangat keren, tetapi sebagian besar outputnya bernilai rendah. Itu karena bayangan dihitung dari bagian atas kanopi pohon, bukan dari permukaan tanah. Jadi bahkan di hutan lebat pun hasilnya terlihat seperti ada sinar matahari masuk saat fajar
  Meski begitu, ini bisa sangat berguna untuk berbagai penggunaan seperti tepi hutan atau vegetasi perkotaan. Untuk kasus penggunaan seperti itu, tile peta bisa jauh lebih kecil, dan data LiDAR mungkin bisa diambil dan dikonversi saat dibutuhkan

• Bukankah ini bisa dikonversi menjadi database SQLite dan disajikan sebagai file statis dengan biaya jauh lebih rendah?
  https://news.ycombinator.com/item?id=27016630
  Range request HTTP yang melakukan sihir utamanya, tetapi bagian itu sudah “terpecahkan”

  • Pada dasarnya itulah jalur yang ditempuh Mapbox. Mapbox bahkan membuat format file mbtiles, yang kurang lebih merupakan DB sqlite, khusus untuk kueri server semacam ini
    Saat ini pendekatan itu cukup dekat dengan “keadaan standar” industri, tetapi bagi developer kecil, yaitu orang seperti saya, masih ada kekurangannya
    Pertama, harus menjalankan server tile terpisah yang menerima permintaan tile dan secara internal mengubahnya menjadi permintaan SQL atau mbtile. Saya kurang suka menambah komponen bergerak
    Kedua, semua GeoTIFF yang sudah lebih dari 10 TB dan terus bertambah harus diproses menjadi mbtiles, dan biaya komputasi serta waktu nyatanya besar
    Ketiga, mbtiles hasilnya paling-paling berukuran mirip dengan GeoTIFF asli, dan dalam kasus buruk bisa jauh lebih besar. Sebagai gantinya permintaan jadi lebih cepat, tetapi biaya hosting dan transfer meningkat. Kalau tertarik, ada tulisan yang menjelaskan optimasi kompresi GeoTIFF dengan baik: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
    Ted mungkin punya pemikirannya sendiri, tetapi setelah beberapa bulan terakhir baru mendalami bidang ini, kira-kira itulah kesimpulan yang saya dapatkan

• Bagus
  Kalau boleh sedikit bercerita dari sudut pandang orang lama yang dulu berkecimpung di teknologi geospasial—mungkin agak terkait dan bisa jadi membosankan—sejak tahun 2000-an pemerintah daerah mulai memesan survei udara LiDAR untuk satu wilayah atau sebagian wilayah, dan lebih jauh lagi muncul tren untuk membuka data digital hasilnya kepada publik
  Sejak lebih dari 10 tahun lalu, para teknisi di sektor swasta sudah rutin menerima dataset LiDAR seluruh kota dalam jumlah besar dan memakainya untuk analisis, peta, dan gambar berskala kecil
  Kebijakan berbagi data pemerintah daerah sangat berbeda-beda antarwilayah, dan kemungkinan besar masih begitu sampai sekarang, tetapi kadang data LiDAR disampaikan dalam bentuk beberapa layer seperti “topografi permukaan tanah”, “bangunan”, dan “kanopi pohon”. Ini adalah hasil yang pertama kali diperoleh dan dihitung oleh operator LiDAR pada berbagai frekuensi
  Para teknisi kantor mencari dan menjalankan prosedur untuk menyesuaikan data sesuai permintaan. Biasanya mereka membuat keluaran berskala kecil dengan perangkat lunak dan rutinitas komersial, dan analisis sinar matahari/bayangan serta analisis viewshed yang sangat mirip dengan yang dibahas di sini juga sudah menjadi layanan yang dipesan saat itu
  Pada pekerjaan berskala lingkungan kecil, gerakan awal untuk memasukkan LiDAR kanopi pohon mulai meresap ke sektor swasta, tetapi itu masih baru dan jarang. Melihat pekerjaan seperti ini sekarang dilakukan dalam skala besar terasa menggembirakan
  Soal penyediaan data berskala besar secara online, pengalaman saya yang sudah seperti dinosaurus hampir tidak ada, tetapi menangani dataset geospasial mentah yang lebih besar selalu menjadi tantangan inti di bidang ini. Pada akhirnya, semua pekerjaan bermuara pada menerjemahkan atau mengabstraksikan sumber semacam itu menjadi keluaran yang efisien, mudah dipahami, dan terfokus sesuai tujuan
  Dalam arti itu, yang benar-benar memberi daya dorong untuk menjadikan inovasi seperti ini praktis dalam skala besar adalah sisi ilmu komputer, lebih spesifiknya ilmu data