LiDAR से पेड़ों की छाया तक गणना करने वाला ShadeMap प्रयोग

 (tedpiotrowski.svbtle.com)
1 पॉइंट द्वारा GN⁺ 2023-07-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ShadeMap अब तक दुनिया भर में आसानी से उपलब्ध radar-based elevation data से छाया की गणना करता रहा है, लेकिन पेड़ों वाले इलाकों में direct sunlight की भविष्यवाणी काफ़ी गलत हो सकती थी
  • LiDAR ज़मीन के साथ-साथ पेड़ों और इमारतों जैसी वस्तुओं की ऊँचाई को भी अधिक सटीक रूप से दर्शा सकता है, जिससे मौसम और समय के अनुसार vegetation shadow simulation संभव होता है
  • वॉशिंगटन राज्य के सार्वजनिक LiDAR dataset की बदौलत Seattle metropolitan area जैसे वास्तविक क्षेत्रों में पेड़ों की छाया सहित rendering का प्रयोग किया जा सका
  • वास्तविक सेवा में लागू करने पर 100GB स्तर के GeoTIFF को browser image tiles में बदलने का conversion काम, memory limits और storage capacity जैसी समस्याएँ साथ आती हैं
  • Seattle metropolitan area का conversion भी 12 घंटे बाद लगभग आधा ही पूरा हुआ और tiles 15GB से आगे निकल गए, इसलिए सार्वजनिक उपलब्धता लागत के कारण छोटे demo तक सीमित है

ShadeMap में पेड़ों की छाया क्यों नहीं थी

  • ShadeMap elevation data का उपयोग करके छाया simulate करता है, और दुनिया भर में आसानी से उपलब्ध elevation datasets SRTM जैसे radar-based data हैं
  • radar रात में भी काम करता है और बादलों के आर-पार जा सकता है, इसलिए satellites अंतरिक्ष से 24 घंटे डेटा इकट्ठा कर सकती हैं
  • Bainbridge Island के 9 जुलाई सुबह 7:09 के rendering comparison में radar-based data vegetation को पर्याप्त रूप से reflect नहीं कर पाया, इसलिए छाया का बड़ा हिस्सा गायब रहा
    • radar केवल ज़मीन से reflect होता है, इस शुरुआती व्याख्या पर HN उपयोगकर्ता ने pointed out किया कि radar vegetation जैसी सतहों से भी reflect होता है, और बाद में correction जोड़ा गया
    • SRTM radar dataset को ground elevation data के source के रूप में उद्धृत किया गया था, इसलिए ऐसा अनुमान बना
  • इसके विपरीत LiDAR अधिक accurate है, लेकिन इसे विमान या drone से इकट्ठा करना पड़ता है और यह धुंध व बादलों के आर-पार नहीं जा सकता
  • डेटा संग्रह में समय और लागत अधिक लगती है, इसलिए हर स्थानीय सरकार को survey cost उठानी पड़ती है

LiDAR डेटा को browser tiles में बदलने का बोझ

  • वॉशिंगटन राज्य एक बड़े क्षेत्र को कवर करने वाला LiDAR dataset उपलब्ध कराता है, और इसका उपयोग ShadeMap की tree shadow simulation को बेहतर बनाने में किया जा सकता है
  • मूल डेटा पारंपरिक GIS software के लिए बने GeoTIFF format में है, इसलिए browser में तेज़ी से load होने वाले JPG या PNG से यह काफ़ी अलग है
  • conversion प्रक्रिया में सैकड़ों GB के floating-point और imperial feet इकाई वाले GeoTIFF files को छोटे image tiles में काटना और metric meters के मानों को लाल, हरे, नीले pixel values में encode करना शामिल है
  • इस काम के दौरान 1TB hard drive खरीदी गई और conversion method के बारे में ChatGPT से पूछते हुए काम आगे बढ़ाया गया
  • 16GB RAM में बड़े data files को एक बार में load करना मुश्किल था, इसलिए conversion code को फिर से लिखना पड़ा ताकि पूरे map की जगह छोटे क्षेत्रों की इकाइयों में processing हो सके
  • केवल Seattle metropolitan area को convert करने पर भी 12 घंटे बाद लगभग आधा काम ही पूरा हुआ, और बने हुए tiles 15GB से आगे बढ़ते रहे
  • नतीजे प्रभावशाली हैं, लेकिन डेटा को सार्वजनिक रूप से host करने की लागत भारी है, इसलिए फिलहाल केवल छोटे क्षेत्र का demo उपलब्ध है
  • अपडेट के बाद shademap.app पर पृथ्वी के बड़े हिस्सों के लिए 1 वर्ग किलोमीटर blocks के आधार पर LiDAR डेटा उपलब्ध कराया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-10
Hacker News टिप्पणियाँ

  • डेमो बहुत शानदार और तेज़ है। मैं अभी पुराने नक्शों और हवाई तस्वीरों के analysis के लिए एक बड़े repository/platform (https://pastmaps.com - अभी बहुत शुरुआती चरण में है, इसलिए ज़्यादा सख़्ती से मत देखिए) पर काम कर रहा हूँ, और tiling pipeline व GeoTIFF के साथ काफ़ी काम कर रहा हूँ
    इसी तरह, source के रूप में raw GeoTIFF files इस्तेमाल करते हुए दिक्कत आई थी, और S3 पर रखी static files पर HTTP range requests लगाकर MapLibre के अंदर एक custom tiling hook बनाया, जिससे tiling की ज़रूरत को bypass किया जा सका। इससे computation client side पर चला जाता है, लेकिन पुराने mobile devices पर भी यह काफ़ी तेज़ चला
    अगर MapLibre में GeoTIFF source support में रुचि है, तो मैं base code या उस काम का कुछ हिस्सा open source में साझा कर सकता हूँ। मुझे लगा था इंटरनेट पर ऐसी चीज़ों से छेड़छाड़ करने वाला अजीब इंसान सिर्फ़ मैं ही हूँ :D

    • आह, मैंने यह नहीं सोचा था कि byte offset को वहीं पर calculate किया जा सकता है। ChatGPT आने से पहले tile generation tools और विकल्पों को समझना मुश्किल था, और online material भी ज़्यादा नहीं था, इसलिए आम तौर पर मुझे लगता है कि ज़्यादा share करना बेहतर है
      मेरे मामले में LiDAR GeoTIFF ब्रिटिश feet units में है और 32-bit floating point precision का उपयोग करता है। अगर sea level से Everest तक की elevation range को meters (8848) में लेकर int16 में रखा जाए, तो 0.2m precision मिल सकती है। ShadeMap के लिए यह काफ़ी है, इसलिए float32 को int16 में बदलने से सैद्धांतिक रूप से cloud storage आधी हो सकती है, और PNG compression को जोड़ें तो इससे भी कम हो सकती है
    • अगर आपने “S3 पर रखी static files पर HTTP range requests लगाकर tiling की ज़रूरत को bypass” किया, तो क्या आपने Cloud Optimized GeoTIFF format भी देखा है, यह जानना चाहूँगा
      https://www.cogeo.org/
      OpenLayers इसे support करता है: https://openlayers.org/en/latest/examples/cog.html
      जहाँ तक मुझे पता है, MapLibre या Leaflet में built-in support नहीं है
    • https://geoblaze-gsoc.vercel.app और उसके underlying libraries भी देखने लायक हैं। ये भी GeoTIFF पर range requests इस्तेमाल करते हैं
      मुझे इस क्षेत्र में बहुत रुचि है, और कुछ projects को आर्थिक रूप से support करने पर भी विचार कर रहा हूँ। मैंने Ted को पहले ही email किया है, लेकिन इस तरह का काम करने वाले किसी भी व्यक्ति से बात करना चाहूँगा। Email profile में है
      अच्छी बात यह है कि यह काफ़ी niche क्षेत्र है, इसलिए inbox फटने की चिंता नहीं है
    • अब आप “सबसे अजीब इंसान” नहीं रहे। फिर भी आप दोनों अभी भी अलग तरह के हैं। अगर आप लोग एक-दूसरे के साथ share करें, बातचीत करें और support करें, तो अच्छा हो सकता है
      मुझे GeoTIFF format में दिक्कत ठीक कहाँ है, यह और सीखना होगा। शायद दोनों projects के बीच pure conversion pipeline infrastructure साझा करना मददगार हो
      अगर दो लोग हैं, तो शायद और लोग भी होंगे जो उसी दीवार से टकराए हैं
    • मुझे भी यह वाकई शानदार लगा। इससे 8 साल पहले Leaflet के core event handling और SVG rendering code को refactor करने का काम याद आ गया। यह जानकर अच्छा लगा कि मेरी open source contribution ने ऐसी शानदार चीज़ों में थोड़ा योगदान दिया

  • यह बात कि “radar vegetation को शामिल नहीं करता, इसलिए बनने वाली छाया का 90% साफ़ तौर पर छूट जाता है। Radar सिर्फ़ ज़मीन से reflect होता है, इसलिए पेड़ और इमारत जैसी चीज़ें दिखाई नहीं देतीं” सही नहीं लगती
    radar कुछ specific bands में पत्तों के आर-पार देख सकता है, जिसे FOPEN कहा जाता है। terrain mapping के लिए ज़रूरी दूरी और coverage speed पर radar इमारतों के आर-पार देख पाता है या नहीं, यह मुझे नहीं पता
    लेख में बताई गई Shuttle Radar Topography Mission ने शायद C-band या X-band radar इस्तेमाल किया होगा, और दोनों में vegetation व buildings से reflection आना चाहिए
    बिना और गहराई में जाए, radar data में vegetation और building shadows न दिखने के कारण ये हो सकते हैं: 1) radar data का resolution बहुत कम था (कई दर्जन meters या उससे ज़्यादा), 2) कई geometric conditions वाले radar passes की post-processing के दौरान उन्हें हटा दिया गया, या 3) radar के low incidence angle की वजह से शुरू से ही shadows बहुत कम बनीं

    • SRTM FAQ को देखें तो लेख का तर्क उल्टा है
      radar ने tree tops को sample किया या ground को, इस पर FAQ कहता है कि वह घने vegetation canopy के आर-पार नहीं देख सका। हो सकता है कि थोड़ा-बहुत canopy के अंदर तक गया हो, लेकिन आम तौर पर उसने canopy के ऊपरी हिस्से के पास का अनुसरण किया
      समस्या यह थी कि radar signal पेड़ों की चोटियों से reflect हुआ, terrain से reflect हुआ, या दोनों के मिश्रण से। geodesist को terrain में रुचि होती है, और forest researchers को canopy height में
      इस्तेमाल की गई 5.6cm wavelength vegetation के आर-पार अच्छी तरह नहीं जा सकी, इसलिए मध्यम से घने vegetation में यह canopy के ऊपरी हिस्से के पास map करती थी। laser altimetry से तुलना करने वाले studies में थोड़ा penetration दिखा, लेकिन ground तक नहीं। जहाँ vegetation sparse था या पत्ते नहीं थे, वहाँ ground reflection मिल सकता था। Earth Observing System के हिस्से के रूप में प्रस्तावित Vegetation Canopy Lidar यह क्षमता दे सकता है, जिससे datasets की दिलचस्प तुलना संभव हो सकती है
      https://www2.jpl.nasa.gov/srtm/faq.html
    • यह अच्छा पूरक है। मेरी समझ से SRTM data में buildings या vegetation शामिल नहीं थे। शायद सबसे कम elevation values को छोड़कर बाकी सब filter कर दिया गया होगा। लेकिन यह सामान्य रूप से “radar” की विशेषता नहीं है
    • SRTMv3 ±60° latitude तक 30m/pixel coverage देता है। शुरुआती release 90m/pixel थी, और एक release ऐसी भी थी जिसमें US के भीतर 30m और बाकी क्षेत्रों के लिए 90m था
      पर्वतीय shadows वास्तव में समस्या हैं। कुछ releases में ऐसे खाली क्षेत्र हैं, ख़ासकर हिमालय के आसपास, जहाँ radar reflection नहीं मिला। अगर रुचि हो, तो SRTM data के void filling पर काफ़ी papers मौजूद हैं

  • अगर GeoTIFF को preprocess करना है और पहले से ऐसा pipeline मौजूद है जो users को terrain elevation देता है, तो शायद tiles में सिर्फ LiDAR और radar के बीच का अंतर encode करके मौजूदा terrain data के ऊपर सिर्फ tree data चढ़ाया जा सकता है। Encode किए जाने वाले object और ज़रूरी precision शायद 4-bit में भी आ जाएँ, और 0 बहुत ज़्यादा होने से compression में गायब हो जाएँगे। यह बस brainstorming के काफ़ी करीब का विचार है

    • यह अच्छा idea है। Elevation data को RGB tiles में encode करने के दो तरीके काफ़ी प्रचलित हैं। दोनों को seabed mapping के लिए negative elevation भी रखना पड़ता है, इसलिए value range के हिसाब से ये size-optimal नहीं हैं
      height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1) [mapbox/maptiler]
      height = (R * 256 + G + B / 256) - 32768 [mapzen terrarium]
      अगर सिर्फ sea level के ऊपर की elevation (0~8848m) चाहिए, तो data को 2 bytes में रखते हुए 0.13m precision बनाए रखी जा सकती है। Mapbox precision 0.1m है
      height = (R * 256 + B) / (256 * 256) * 8848 [shademap]
      इसी encoding का उपयोग करने की योजना है। इसे पहले ही test कर चुका हूँ और इससे space बचता है। Processing time के बारे में पक्का नहीं पता
      सबसे अच्छी encoding यह होगी कि पूरे tile की सबसे कम elevation को header में रखा जाए, और tile की minimum elevation और हर pixel elevation के बीच का सिर्फ difference value store किया जाए। Space efficiency सबसे बेहतर होगी, लेकिन minimum elevation निकालने के लिए पूरे tile data को memory में लाना पड़ेगा, और pixels को एक-एक करके stream करते हुए encode करने से यह कम efficient है
    • मैं सच में इस क्षेत्र के बारे में और जानना चाहता हूँ। अगला किस विषय पर focus करूँ, यह ढूँढ़ रहा हूँ, और यहाँ आए terms ठीक उसी knowledge level से मेल खाते हैं जहाँ मैं पहुँचना चाहता हूँ
      topological data science में निपुण होने के लिए क्या पढ़ना चाहिए, यह कोई बताए तो अच्छा होगा

  • मुझे Shademaps पसंद है। काश मेरा वह product, जो इसे इस्तेमाल करता है, ज़्यादा सफल होता, लेकिन Ted और Shademaps शानदार हैं। Trees जोड़ना बहुत practical है। इस tool का उपयोग करने वाली कई जगहें urban हैं, लेकिन जहाँ ऐसा नहीं है, वहाँ tree data लगभग हमेशा buildings या elevation से ज़्यादा महत्वपूर्ण होता है। Ontario काफ़ी flat है, और मेरे 99% users वहीं हैं

    • business और marketing की तरफ़ अभी भी थोड़ी जद्दोजहद चल रही है, लेकिन idea खुद काफ़ी पसंद किया जा रहा है, और काम मज़ेदार और संतोषजनक है

  • यह किसी GIS company के interview question जैसा लगता है: “अगर आपके पास radar और LiDAR data हो, और memory-constrained device पर इन्हें merge करना हो, तो आप कैसे करेंगे?”

    • कुछ मायनों में यहाँ की problems वही हैं जिनके लिए computer science education ने तैयार किया था। पहले मैं web development में था, और बहुत कम ही यह सोचना पड़ता था कि web page memory में आएगा या नहीं, या processor के उपलब्ध cycles का कुछ प्रतिशत से ज़्यादा इस्तेमाल होगा

  • फ्रांस की mapping service ने पूरे फ्रांस के लिए HD LiDAR imaging शुरू की है, और उसका कुछ हिस्सा पहले से उपलब्ध है: https://geoservices.ign.fr/lidarhd नीचे की तरफ़ है
    जानना चाहता हूँ कि क्या कभी इस data को app में शामिल करने की योजना है

    • बिल्कुल। लिंक के लिए धन्यवाद
      अभी मुख्य रुकावट यह है कि मेरी मंगेतर summer vacation पर है (वह teacher है), इसलिए हम काफ़ी बाहर जाते हैं, और ऑनलाइन LiDAR datasets ढूँढ़ना भी मुश्किल है
      लगता है Washington data काफ़ी समय से मौजूद था, लेकिन मुझे कुछ हफ़्ते पहले तक उसके बारे में पता नहीं था
      उम्मीद है कि किसी दिन LiDAR datasets पर ASK HN पोस्ट करूँगा और जितना हो सके उतना data crowdsource कर पाऊँगा

  • शानदार project है
    data को Requester Pays enabled S3 bucket में host करने के बारे में क्या ख़याल है? तब आपको सिर्फ storage cost उठानी होगी
    anonymous access संभव नहीं रहेगा (Dropbox sharing में भी यही होता है), लेकिन cost बहुत कम हो जाएगी
    https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
    चूँकि यह read-only है, इसलिए ज़रूरी नहीं कि SQL frontend हो, और SQLite को S3 bucket में database access कराने के कई तरीके भी हैं। उदाहरण: https://github.com/michalc/sqlite-s3-query

  • demo बहुत शानदार है, लेकिन output का ज़्यादातर हिस्सा कम मूल्य का है। क्योंकि shadows की गणना ground पर नहीं बल्कि tree canopy के top पर की जा रही है। इसलिए घने जंगल में भी यह ऐसे दिखता है जैसे सुबह-सुबह धूप आ रही हो
    फिर भी forest edge या urban vegetation जैसे कई उपयोगों के लिए यह बहुत उपयोगी हो सकता है। ऐसे use cases में map tiles काफ़ी छोटे हो सकते हैं, और LiDAR data को ज़रूरत पड़ने पर fetch करके transform भी किया जा सकता है

  • क्या इसे SQLite database में convert करके बहुत कम लागत वाली static file के रूप में serve नहीं किया जा सकता?
    https://news.ycombinator.com/item?id=27016630
    HTTP के range requests ही असली जादू करते हैं, लेकिन वह हिस्सा पहले से “solved” है

    • मूल रूप से Mapbox ने यही रास्ता अपनाया था। Mapbox ने तो इस तरह के server queries के लिए sqlite DB जैसे mbtiles file format तक बना दिया
      आज के समय में यह industry की “standard state” के काफ़ी करीब का तरीका है, लेकिन मेरे जैसे छोटे developer के लिए इसमें अब भी कमियाँ हैं
      पहली बात, tile requests लेने और उन्हें अंदरूनी रूप से SQL requests या mbtile requests में बदलने के लिए अलग tile server चलाना पड़ता है। मुझे moving parts बढ़ाना ज़्यादा पसंद नहीं
      दूसरी बात, 10TB से ज़्यादा और लगातार बढ़ते GeoTIFF को पूरा mbtiles में process करना पड़ता है, जिसमें computation cost और actual time दोनों बहुत लगते हैं
      तीसरी बात, बनने वाले mbtiles ज़्यादा से ज़्यादा मूल GeoTIFF जितने ही छोटे होते हैं, और खराब स्थिति में उनसे बहुत बड़े हो जाते हैं। Faster requests मिलती हैं, लेकिन hosting और transfer cost बढ़ जाती है। अगर दिलचस्पी हो तो GeoTIFF compression optimization पर यह अच्छी तरह समझाने वाला लेख है: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
      Ted के अपने विचार भी होंगे, लेकिन पिछले कुछ महीनों में इस क्षेत्र में नए सिरे से गहराई में जाने के बाद मेरी निष्कर्ष-रेखा फिलहाल यही है

  • अच्छा
    भू-स्थानिक तकनीक में काम कर चुके पुराने लोगों के नज़रिए से थोड़ा संबंधित और शायद उबाऊ लगने वाली बात कहूँ तो, 2000 के दशक से स्थानीय सरकारों ने क्षेत्र-स्तर या आंशिक क्षेत्र-स्तर पर LiDAR हवाई सर्वेक्षण का ठेका देना शुरू किया, और आगे बढ़कर उसके डिजिटल नतीजों को आम जनता के लिए उपलब्ध कराने की प्रवृत्ति भी उभरी।
    10 साल से भी पहले से निजी क्षेत्र के तकनीशियन पूरे शहर के LiDAR datasets बड़ी मात्रा में लेकर उन्हें छोटे पैमाने के analysis, maps और drawings में रोज़मर्रा के इस्तेमाल के लिए उपयोग करते रहे हैं।
    स्थानीय सरकारों की data-sharing policies क्षेत्र के अनुसार बहुत अलग थीं, और संभव है कि आज भी हों, लेकिन कभी-कभी LiDAR data को “surface terrain”, “building”, “tree canopy” जैसी कई layers के रूप में दिया जाता था। यह LiDAR operators द्वारा अलग-अलग frequencies पर शुरुआती संग्रह और गणना से निकला हुआ परिणाम था।
    दफ़्तरों में काम करने वाले तकनीशियन मांग के अनुसार data को समायोजित करने की प्रक्रिया ढूँढते और लागू करते थे। आम तौर पर वे commercial software और routines से छोटे पैमाने के outputs बनाते थे, और यहाँ चर्चा हो रही sunlight/shade analysis तथा viewshed analysis जैसी सेवाएँ उस समय भी पहले से मंगाई जाती थीं।
    छोटे मोहल्ला-स्तर के कामों में tree canopy LiDAR को शामिल करने की शुरुआती कोशिशें निजी क्षेत्र में फैलनी शुरू हुई थीं, लेकिन यह नया और दुर्लभ था। आज इस तरह का काम बड़े पैमाने पर होते देखना उत्साहजनक है।
    बड़े पैमाने पर data को online उपलब्ध कराने के काम का मेरा अनुभव लगभग नाममात्र का है, लेकिन बड़े स्तर के raw geospatial datasets को संभालना हमेशा इस क्षेत्र की मुख्य चुनौतियों में रहा है। आखिरकार, सारा काम ऐसे स्रोतों को कुशल, समझने में आसान और उद्देश्य के अनुसार केंद्रित output में translate या abstract करने पर आ टिकता है।
    इस अर्थ में, ऐसे innovation को बड़े पैमाने पर व्यवहारिक बनाने की असली प्रेरक शक्ति computer science, और अधिक विशेष रूप से data science का पक्ष है।