2 पॉइंट द्वारा GN⁺ 2025-10-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दुनिया भर के विशाल OpenStreetMap(OSM) dataset को और तेज़ व अधिक कुशल तरीके से संभालने के लिए नया फ़ाइल फ़ॉर्मैट GOB(Geo-Object Bundle) पेश किया गया है
  • GOB, मौजूदा Geo-Object Library(GOL) का compressed version है, जिसमें index हटाकर आकार घटाया गया है और processing speed बढ़ाई गई है
  • GOB फ़ाइलें PBF से औसतन 30% छोटी हैं, GOL की तुलना में लगभग आधी हैं, और import speed 5 गुना तेज़ है
  • tile-based structure की वजह से क्षेत्र-आधारित extraction और merge आसान है, और कम क्षमता वाले सिस्टम पर भी तेज़ loading संभव है
  • इसमें metadata और edit history शामिल नहीं होती, लेकिन distribution और archival format के रूप में इसकी उपयोगिता बहुत अधिक है

GOB फ़ॉर्मैट का अवलोकन

  • GOB, OpenStreetMap(OSM) डेटा को अधिक छोटे और तेज़ तरीके से संभालने के लिए बनाया गया नया फ़ाइल फ़ॉर्मैट है
    • यह मौजूदा GOL की तुलना में लगभग आधा आकार रखता है, और PBF से औसतन 30% अधिक छोटा है
    • बड़े पैमाने के डेटा processing के लिए compression और tile-based structure अपनाई गई है
  • GOB, GeoDesk Toolkit का हिस्सा है और open source के रूप में उपलब्ध है
    • GOL Tool 2.1 version में GOB save (save) और load (load) feature उपलब्ध हैं

प्रदर्शन और दक्षता

  • GOB, मौजूदा फ़ॉर्मैट्स की तुलना में 5 गुना तेज़ import speed देता है
    • PBF से GOL build करने में लगने वाले समय की तुलना में यह बहुत कम समय लेता है
    • आधुनिक सिस्टम पर पूरे planet का डेटा 3 मिनट में load किया जा सकता है
    • 32GB से कम memory पर भी यह कुशलता से काम करता है, इसलिए पुराने laptop पर भी एक घंटे के भीतर processing संभव है
  • आकार तुलना के उदाहरण (PBF → GOB):
    • Planet: 65.4GB → 46.0GB (-29.7%)
    • France: 4.54GB → 2.84GB (-36.3%)
    • Japan: 2.13GB → 1.34GB (-37.0%)
  • जितना अधिक डेटा dense होगा, compression efficiency उतनी ही बेहतर होगी; Brazil, China जैसे कम data density वाले क्षेत्रों में कमी लगभग 23% रहती है

संरचना और उपयोग का तरीका

  • GOB, tile unit पर आधारित है और map tile renderer की zoom structure (zoom 6~12) की नकल करता है
    • पूरे planet का डेटा लगभग 60 हज़ार tiles से बना है
    • क्षेत्र-विशिष्ट डेटा को फ़ाइल कॉपी के बराबर गति से extract और merge किया जा सकता है
  • इस संरचना की वजह से क्षेत्र-वार storage, distribution और partial update आसान हो जाते हैं

सीमाएँ

  • GOB में metadata (editor name, timestamp आदि) और edit history शामिल नहीं होती
    • यह editing के बजाय distribution और archive उद्देश्यों के लिए optimize किया गया है
    • data को up-to-date रखने के लिए नया GOB snapshot फिर से बनाना होगा

उपयोग कैसे करें

  • GOB, GOL Tool 2.1 या उससे ऊपर के version में इस्तेमाल किया जा सकता है
    • gol save <gol-file> [<gob-file>] कमांड से GOL को GOB में convert करें
    • gol load <gol-file> [<gob-file>] कमांड से GOB को GOL में load करें
  • --area option का उपयोग करके GeoJSON, WKT, coordinates के जरिए किसी खास क्षेत्र को ही export/load किया जा सकता है
    • उदाहरण: gol save world bodensee -a 9.55,47.4,8.78,47.66,9.01,47.88,9.85,47.58,9.82,47.46

उपलब्ध dataset और आगे की योजना

  • Open Planet Data पर रोज़ update होने वाली वैश्विक GOB फ़ाइलें (50GB से कम) वितरित की जाती हैं
  • डेवलपर आगे और सुधार पर काम कर रहे हैं:
    • zlib के अलावा अन्य compression algorithm पर प्रयोग (zstd से कोई खास सुधार नहीं मिला)
    • आगे gol load में URL से सीधे GOB load करने की सुविधा जोड़ी जाएगी
    • इसके जरिए “डाउनलोड के साथ-साथ background build” द्वारा व्यावहारिक रूप से 0 मिनट import का लक्ष्य हासिल करने की योजना है

1 टिप्पणियां

 
GN⁺ 2025-10-26
Hacker News टिप्पणी
  • नए GOB format की spec जानने के लिए खोजा। अभी कोई आधिकारिक spec नहीं है, लेकिन details पर चर्चा करने वाला thread है
    यह सिर्फ OSM तक सीमित नहीं है; spatial indexing को support करने वाला high-performance spatial data format किसी app की usability और productivity पर बड़ा असर डालता है
    उदाहरण के लिए, QGIS में बड़े data को KMZ (zipped XML) के रूप में save करने पर वह कई मिनट तक रुक जाता है, लेकिन वही data flatgeobuf में save करने पर तुरंत load हो जाता है

    • शायद फर्क यह है कि KMZ streaming नहीं कर सकता, इसलिए पूरे data को memory में लाने के बाद QGIS के internal structure में convert करना पड़ता है
      मेरा अनुभव है कि complex KMZ/KML दूसरे GIS apps में भी ठीक से import नहीं होते
      जानना चाहूंगा कि वही data GeoJSON में लिखने पर कैसा रहता है
    • QGIS में मुझे लगा कि data को Postgres पर डालकर इस्तेमाल करना performance के हिसाब से कहीं बेहतर है
  • मैं जानना चाहता हूं कि क्या यह format नया OSM data model इस्तेमाल करता है
    संबंधित सामग्री के तौर पर data model research report, GitHub repository, और official blog पर feedback request post हैं
    मौजूदा model में coordinates को node references में बदलने की प्रक्रिया धीमी है और RAM बहुत ज्यादा इस्तेमाल करती है, इसलिए यह झंझट भरी लगती है

  • GIS से जुड़ा एक सवाल है। मैं LIDAR point cloud को mesh में बदलने का अच्छा तरीका खोज रहा हूं
    building walls जैसी लगभग vertical जगहों पर data sparse है, और point normals भी नहीं हैं, इसलिए Poisson, Ball Pivot, या Meshlab के VCG जैसे आम तरीके degenerate results देते हैं या बहुत धीमे हैं
    tree canopy और eaves की वजह से साधारण heightmap approach की भी सीमा है
    मैं लगभग 90 अरब points को 3 करोड़ से 5 करोड़ triangles तक घटाना चाहता हूं, लेकिन इसके लिए महीनों तक custom pipeline develop नहीं करना चाहता

    • 3DBAG project आज़माने लायक है। यह Netherlands के 1.1 करोड़ buildings को LiDAR और building outlines से reconstruct करने वाला open source project है
      इसका GitHub repository और reconstruction pipeline भी public हैं
    • Meshroom अब LIDAR data को input के रूप में ले सकता है
      पहले मैंने इसे photogrammetry और VFX के camera tracking के लिए इस्तेमाल किया था, और इस तरह के काम के लिए यह बहुत मजबूत open source toolkit था
  • मेरी राय में, अगर libosmium और GDAL इसे support नहीं करते, तो यह format अभी भी सीमित दायरे में ही रह जाएगा

    • लेकिन इसका मतलब यह नहीं कि उनके पास support न करने की कोई वजह है
      यह अभी तैयार spec भी नहीं, बस idea stage में है, इसलिए हर नया format शुरुआत में ऐसे ही रहता है
  • मैं जानना चाहता हूं कि क्या यह osmium के साथ compatible है

    • अभी नहीं। यह format अभी-अभी पेश किया गया है, इसलिए औपचारिक spec तक नहीं है