LiDAR ile ağaç gölgelerini de hesaplayan ShadeMap deneyi
(tedpiotrowski.svbtle.com)- ShadeMap şimdiye kadar dünya genelinde kolayca bulunabilen radar tabanlı yükseklik verileri ile gölgeleri hesaplıyordu, ancak ağaçlık bölgelerde doğrudan güneş ışığı tahminleri ciddi biçimde sapabiliyordu
- LiDAR, yalnızca zemini değil ağaçlar ve binalar gibi nesnelerin yüksekliklerini de daha hassas biçimde yansıtabildiği için, mevsime ve günün saatine göre bitki örtüsü gölgelerini simüle etmeyi mümkün kılıyor
- Washington eyaletinin açık LiDAR veri seti sayesinde Seattle metropolitan area gibi gerçek bölgelerde ağaç gölgelerini içeren render denemeleri yapılabildi
- Gerçek hizmete uygulamak için 100 GB ölçeğindeki GeoTIFF dosyalarını tarayıcıya uygun görüntü döşemelerine dönüştürme işiyle birlikte bellek sınırları ve depolama kapasitesi sorunları ortaya çıkıyor
- Seattle metropolitan area dönüşümü bile 12 saatin sonunda ancak yarıya gelebildi ve döşemeler 15 GB’ı aştı; herkese açık sunum, maliyet yükü nedeniyle küçük bir demo ile sınırlı kaldı
ShadeMap'te neden ağaç gölgesi yoktu?
- ShadeMap, yükseklik verilerini kullanarak gölgeleri simüle ediyor ve dünya genelinde kolayca bulunabilen yükseklik veri setleri SRTM gibi radar tabanlı veriler
- Radar gece de çalışabilir ve bulutların içinden geçebilir; bu sayede uydular uzaydan günün 24 saati veri toplayabilir
- Bainbridge Island için 9 Temmuz saat 07:09 render karşılaştırmasında, radar tabanlı veriler bitki örtüsünü yeterince yansıtamadığı için gölgelerin önemli bir kısmı eksik kalıyordu
- Radarın yalnızca yer yüzeyinden yansıdığına dair ilk açıklamaya bir HN kullanıcısı itiraz ederek radarın bitki örtüsü gibi yüzeylerden de yansıdığını belirtti; daha sonra buna dair bir düzeltme eklendi
- SRTM radar veri seti yer yüzeyi yükseklik verisinin kaynağı olarak gösterildiği için böyle bir varsayım oluştu
- Buna karşılık LiDAR daha doğru, ancak verinin uçak veya drone ile toplanması gerekiyor ve sisle bulutların içinden geçemiyor
- Toplama süreci zaman ve maliyet açısından ağır olduğu için ölçüm masrafını yerel yönetimlerin üstlenmesi gerekiyor
LiDAR verisini tarayıcı döşemelerine dönüştürmenin yükü
- Washington eyaleti geniş bir alanı kapsayan LiDAR veri seti sunuyor ve bu veri, ShadeMap'in ağaç gölgesi simülasyonunu iyileştirmek için kullanılabiliyor
- Ham veri, geleneksel GIS yazılımlarına uygun GeoTIFF biçiminde olduğundan, tarayıcıda hızlı yüklemeye uygun JPG veya PNG formatlarından oldukça farklı
- Dönüştürme işi, yüzlerce GB büyüklüğündeki kayan noktalı ve imperial feet birimli GeoTIFF dosyalarını küçük görüntü döşemelerine bölmeyi ve metric meters değerlerini kırmızı, yeşil ve mavi piksel değerlerine kodlamayı içeriyor
- Süreçte 1 TB sabit disk satın alındı ve dönüştürme yöntemi için ChatGPT'ye danışıldı
- 16 GB RAM ile büyük veri dosyalarını tek seferde yüklemek zor olduğundan, dönüştürme kodunun tüm harita yerine küçük alan birimleri işleyecek şekilde yeniden yazılması gerekti
- Yalnızca Seattle metropolitan area dönüştürülürken bile 12 saatin ardından ancak yaklaşık yarısı tamamlanabildi ve üretilen döşemeler 15 GB’ı geçmiş durumda büyümeyi sürdürüyordu
- Sonuç etkileyici olsa da veriyi herkese açık şekilde barındırmanın maliyeti yüksek olduğu için şu anda yalnızca küçük bir alan demo olarak sunuluyor
- Güncellemeden sonra shademap.app, Dünya'nın büyük bir bölümü için 1 kilometrekarelik bloklar halinde LiDAR verisi sunabilir hale geldi
1 yorum
Hacker News görüşleri
Demo inanılmaz havalı ve hızlı. Şu sıralar geçmiş haritalar ve hava fotoğraflarının analizi için büyük ölçekli bir depo/platform (https://pastmaps.com - henüz çok erken aşamada, o yüzden fazla sert yargılamayın) oluştururken döşeme hattı ve GeoTIFF ile epey uğraşıyorum
Benzer şekilde ham GeoTIFF dosyalarını kaynak olarak kullanırken sorun yaşadım ve S3’e yüklenmiş statik dosyalara HTTP aralık istekleri ekleyip MapLibre içinde özel bir döşeme kancası oluşturarak döşeme ihtiyacını aşabildim. Hesaplamayı istemci tarafına itiyor ama eski mobil cihazlarda bile oldukça hızlı çalışıyordu
MapLibre’in GeoTIFF kaynak desteğiyle ilgileniyorsanız temel kodu ya da o çalışmanın bir kısmını açık kaynak olarak paylaşabilirim. İnternette bununla uğraşan tek manyağın ben olduğumu sanıyordum :D
Benim durumumda LiDAR GeoTIFF verileri İngiliz tipi fit biriminde ve 32 bit kayan nokta hassasiyetinde. Deniz seviyesinden Everest’e kadar yükseklik aralığını metre cinsinden (8848) alıp int16 içine koyarsanız 0.2 m hassasiyet elde edebilirsiniz. ShadeMap için yeterli olur; dolayısıyla float32’yi int16’ya çevirmek teorik olarak bulut depolama alanını yarıya indirebilir ve PNG sıkıştırması da hesaba katılırsa daha da düşebilir
https://www.cogeo.org/
OpenLayers destekliyor: https://openlayers.org/en/latest/examples/cog.html
Bildiğim kadarıyla MapLibre veya Leaflet’te yerleşik destek yok
Bu alana çok ilgi duyuyorum ve birkaç projeyi maddi olarak desteklemeyi de düşünüyorum. Ted’e zaten e-posta attım ama bu tür işler yapan herkesle konuşmak isterim. E-posta adresim profilimde var
Neyse ki alan yeterince niş, o yüzden gelen kutumun patlamasından endişe etmiyorum
GeoTIFF formatında sorunun tam olarak nerede olduğunu daha fazla öğrenmem gerekecek. İki proje arasında saf dönüşüm hattı altyapısını paylaşmak faydalı olabilir
İki kişi varsa, aynı duvara toslayan başkaları da olabilir
“Radar, bitki örtüsünü içermediği için oluşan gölgelerin %90’ını açıkça kaçırıyor. Radar yalnızca zeminden yansır, bu yüzden ağaçlar ve binalar gibi nesneler görünmez” açıklaması doğru görünmüyor
Radar belirli bantlarda yaprakların içinden görebilir; buna FOPEN denir. Arazi haritalamada gereken mesafe ve kapsama hızlarında radarın binaların içinden görmesi konusunda ise bilgim yok
Yazıda bahsedilen Shuttle Radar Topography Mission muhtemelen C-bandı veya X-bandı radar kullanıyordu; her ikisinde de bitki örtüsü ve binalardan yansıma alınması gerekir
Daha derine inmeden, radar verisinde bitki örtüsü ve bina gölgelerinin olmamasının nedeni 1) radar verisinin çözünürlüğünün çok düşük olması (onlarca metre veya daha fazla), 2) farklı geometrik koşullardaki radar geçişlerinin sonradan işlenirken bunların kaldırılmış olması veya 3) radarın düşük geliş açısı nedeniyle baştan beri pek gölge oluşmaması olabilir
Radarın ağaç tepelerini mi yoksa zemini mi örneklediği konusunda SSS, kalın bitki örtüsü örtüsünün içinden göremediğini açıklıyor. Biraz örtünün içine girmiş olabilir ama genel olarak örtünün üst kısmına yakın bir yüzeyi takip etmiş deniyor
Sorun, radar sinyalinin ağaç tepelerinden mi, araziden mi yoksa ikisinin birleşiminden mi yansıdığıydı. Jeodeziciler araziyle ilgilenir, orman araştırmacıları ise örtü yüksekliğiyle
Kullanılan 5.6 cm dalga boyu bitki örtüsünü iyi nüfuz edemediği için orta ila yoğun bitki örtüsünde örtünün üst kısmına yakın bölgeyi haritaladı. Lazer altimetre ile karşılaştırılan çalışmalarda biraz nüfuz ettiği görüldü ama zemine kadar ulaşmadı. Bitki örtüsünün seyrek olduğu ya da yaprak bulunmadığı durumlarda zemin yansımaları alınabiliyordu. Earth Observing System’in bir parçası olarak planlanan Vegetation Canopy Lidar bu yeteneği sağlayarak ilginç veri seti karşılaştırmalarını mümkün kılabilir
https://www2.jpl.nasa.gov/srtm/faq.html
Dağ gölgeleri gerçekten bir sorun. Bazı sürümlerde, özellikle Himalayalar çevresi gibi radar yansıması alınamayan yerlerde boş alanlar bulunuyor. İlgileniyorsanız SRTM verisindeki boş alanların doldurulması üzerine epey makale var
GeoTIFF ön işleniyorsa ve kullanıcıya arazi yüksekliğini zaten sağlayan bir pipeline varsa, tile içine LiDAR ile radar arasındaki fark kodlanıp mevcut arazi verisinin üstüne yalnızca ağaç verisi bindirilebilir gibi görünüyor. Kodlanacak nesneler ve gereken hassasiyet 4 bit civarına sığabilir, ayrıca çok sayıda 0 olduğu için sıkıştırmayla büyük ölçüde yok olabilir. Daha çok beyin fırtınasına yakın bir fikir sadece
height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)[mapbox/maptiler]height = (R * 256 + G + B / 256) - 32768[mapzen terrarium]Yalnızca deniz seviyesi üstündeki yükseklik gerekiyorsa (0~8848m), veri 2 bayt içinde tutulurken 0.13 m hassasiyet korunabilir. Mapbox hassasiyeti 0.1 m
height = (R * 256 + B) / (256 * 256) * 8848[shademap]Kullanmayı planladığım kodlama bu. Zaten denedim ve yer kazandırıyor. İşleme süresinin nasıl olacağını henüz bilmiyorum
En iyi kodlama, tüm tile'ın en düşük yüksekliğini header'a koyup, tile'ın en düşük yüksekliğiyle her piksel yüksekliği arasındaki fark değerini saklamak olur. Alan verimliliği en yüksek olan bu, ama en düşük yüksekliği bulmak için tüm tile verisini belleğe almak gerekiyor ve pikselleri tek tek stream ederek kodlamaktan daha az verimli
Topoğrafik veri bilimi konusunda yetkinleşmek için ne çalışmam gerektiğini söylerlerse harika olur
Shademaps'i seviyorum. Bunu kullanan ürünümün daha başarılı olmasını isterdim ama Ted ve Shademaps harika. Ağaç eklemek son derece pratik. Bunu kullanan birçok bölge kentsel alan olsa da, öyle olmayan yerlerde ağaç verisi neredeyse her zaman bina ya da yükseklikten daha önemli. Ontario epey düz ve kullanıcılarımın %99'u orada
GIS şirketi mülakatında sorulacak türden bir soru: “Elinizde radar ve LiDAR verisi var ve belleği kısıtlı bir cihazda bunları birleştirmek istiyorsunuz; bunu nasıl yaparsınız?”
Fransa'nın harita servisi, tüm Fransa için HD LiDAR çekimlerine başladı ve bir kısmı şimdiden erişilebilir durumda: https://geoservices.ign.fr/lidarhd aşağı tarafta
Bir gün bu veriyi uygulamaya eklemeyi planlayıp planlamadığınızı merak ediyorum
Şu anda ana engel, nişanlımın yaz tatilinde olması (öğretmen) nedeniyle dışarıda çok zaman geçirmemiz ve çevrimiçi LiDAR veri setlerini bulmanın da zor olması
Washington verisi uzun zamandır varmış gibi duruyor ama birkaç hafta öncesine kadar varlığından haberim yoktu
Bir gün LiDAR veri setleri hakkında bir ASK HN açıp olabildiğince fazla veriyi crowdsourcing ile toplamayı umuyorum
Harika bir proje
Veriyi Requestor Pays etkin bir S3 bucket'ta barındırmak nasıl olur? Böylece yalnızca depolama maliyetini üstlenirsiniz
Anonim erişim mümkün olmazdı (Dropbox paylaşımı için de aynı durum geçerli), ama maliyet ciddi biçimde düşerdi
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
Salt okunur olduğu için mutlaka bir SQL frontend gerekmez; ayrıca SQLite'ın S3 bucket içindeki veritabanına erişmesini sağlayan çeşitli yöntemler de var. Örn: https://github.com/michalc/sqlite-s3-query
Demo çok etkileyici, ancak çıktının büyük kısmının değeri düşük. Çünkü gölgeler zemin yerine ağaç örtüsünün üst kısmına göre hesaplanıyor. Bu yüzden sık ormanda bile sabah erken saatlerde güneş varmış gibi görünüyor
Yine de orman kenarları veya kentsel bitki örtüsü gibi birçok kullanım için oldukça yararlı olabilir. Bu tür kullanım senaryolarında harita tile'ları çok daha küçük olabilir ve LiDAR verisi gerektiğinde çekilip dönüştürülebilir gibi duruyor
Bunu SQLite veritabanına dönüştürüp çok daha düşük maliyetli statik dosyalar olarak sunmak mümkün değil mi?
https://news.ycombinator.com/item?id=27016630
HTTP'nin range request özelliği asıl sihri yapıyor, ama o kısım zaten “çözülmüş” durumda
Bu, günümüzde sektörün “standarda en yakın” yaklaşımı ama benim gibi küçük geliştiriciler için hâlâ bazı dezavantajları var
Birincisi, tile isteklerini alıp bunları içerde SQL sorgularına ya da mbtile isteklerine çeviren ayrı bir tile sunucusu çalıştırmak gerekiyor. Hareketli parçaların artmasını pek sevmiyorum
İkincisi, 10 TB'tan büyük ve sürekli büyüyen GeoTIFF'lerin tamamını mbtiles'a dönüştürmek zorundayım; bunun hesaplama maliyeti de gerçek dünyadaki süresi de yüksek
Üçüncüsü, ortaya çıkan mbtiles dosyaları en iyi ihtimalle kaynak GeoTIFF kadar büyük oluyor, kötü senaryoda ise çok daha büyük. Daha hızlı istekler elde ediyorsunuz ama barındırma ve aktarım maliyetleri artıyor. İlgileniyorsanız GeoTIFF sıkıştırma optimizasyonunu iyi anlatan bir yazı var: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
Ted'in de kendine göre fikirleri vardır ama son birkaç aydır bu alana yeni girmiş biri olarak vardığım sonuçlar bunlar
Güzel
Jeo-uzamsal teknolojiyle uğraşmış eski kuşaktan biri olarak, biraz ilgili ama sıkıcı olabilecek bir şey söylemem gerekirse, 2000’lerden itibaren yerel yönetimler bölge bazında ya da bazı alt bölgeler bazında LiDAR hava ölçümü sipariş etmeye başladı ve daha da ileri giderek ortaya çıkan dijital verileri kamuya açma yönünde bir eğilim oluştu.
10 yıldan da uzun süre önce özel sektördeki teknisyenler, şehir ölçeğindeki LiDAR veri setlerini toplu halde alıp bunları küçük ölçekli analizler, haritalar ve çizimlerde rutin olarak kullanıyordu.
Yerel yönetimlerin veri paylaşım politikaları bölgeden bölgeye büyük farklılık gösteriyordu ve muhtemelen hâlâ da öyledir; ancak LiDAR verileri bazen “yüzey topoğrafyası”, “binalar”, “ağaç örtüsü” gibi birden çok katman halinde sunuluyordu. Bunlar, LiDAR operatörünün farklı frekanslarda ilk elde topladığı ve hesapladığı sonuçlardı.
Ofis teknisyenleri, taleplere göre veriyi uyarlamak için gereken prosedürleri bulup uyguluyordu. Genelde ticari yazılımlar ve rutin iş akışlarıyla küçük ölçekli çıktılar üretiyorlardı; burada ele alınana çok benzeyen güneşlenme/gölgeleme analizi ile görünürlük analizleri de o dönemde zaten talep edilen hizmetlerdi.
Mahalle ölçeğindeki küçük işlerde ağaç örtüsü LiDAR’ını da dahil etmeye yönelik ilk hareketler özel sektöre sızmaya başlamıştı, ama bu yeni ve nadir bir durumdu. Bugün bu tür çalışmaların büyük ölçekte yapıldığını görmek cesaret verici.
Büyük veriyi çevrimiçi sunma konusunda benim dinozor sayılabilecek deneyimim pek yok, ama daha büyük ölçekli ham jeo-uzamsal veri setleriyle çalışmak bu alanın her zaman temel meselelerinden biriydi. Sonuçta bütün iş, bu tür kaynakları verimli, anlaşılması kolay ve amaca odaklı çıktılara dönüştürmek ya da soyutlamakla ilgili.
Bu anlamda, bu tür yenilikleri büyük ölçekte pratik hale getirmeye gerçekten ivme kazandıran şey bilgisayar bilimi, daha spesifik olarak da veri bilimi tarafı