GOB รูปแบบไฟล์ใหม่ของ OSM เล็กกว่า PBF 30% และนำเข้าได้เร็วกว่า 5 เท่า

 (community.openstreetmap.org)
2 คะแนน โดย GN⁺ 2025-10-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเปิดตัวรูปแบบไฟล์ใหม่ GOB (Geo-Object Bundle) เพื่อจัดการ ชุดข้อมูล OpenStreetMap (OSM) ขนาดมหาศาล ทั่วโลกได้รวดเร็วและมีประสิทธิภาพยิ่งขึ้น
  • GOB เป็นเวอร์ชันบีบอัดของ Geo-Object Library (GOL) เดิม โดยตัดดัชนีออกเพื่อลดขนาดและเพิ่มความเร็วในการประมวลผล
  • ไฟล์ GOB มีขนาดเล็กกว่า PBF โดยเฉลี่ย 30% และเล็กกว่า GOL ราวครึ่งหนึ่ง ขณะที่ ความเร็วในการนำเข้าสูงกว่า 5 เท่า
  • ด้วย โครงสร้างแบบอิงไทล์ จึงดึงและรวมข้อมูลตามพื้นที่ได้ง่าย และโหลดได้รวดเร็วแม้บนระบบสเปกต่ำ
  • แม้จะไม่รวมเมทาดาทาและประวัติการแก้ไข แต่ก็ เหมาะอย่างยิ่งสำหรับการแจกจ่ายและจัดเก็บเป็นไฟล์ถาวร

ภาพรวมของรูปแบบ GOB

  • GOB เป็นรูปแบบไฟล์ใหม่สำหรับจัดการข้อมูล OpenStreetMap (OSM) ให้เล็กลงและเร็วขึ้น
    • มีขนาดเพียงครึ่งเดียวของ GOL เดิม และ เล็กกว่า PBF โดยเฉลี่ย 30%
    • ใช้ โครงสร้างแบบบีบอัดและอิงไทล์ สำหรับการจัดการข้อมูลขนาดใหญ่
  • GOB เป็นส่วนหนึ่งของ GeoDesk Toolkit และเปิดให้ใช้งานแบบโอเพนซอร์ส
    • รองรับการบันทึก (save) และโหลด (load) GOB ใน GOL Tool 2.1

ประสิทธิภาพและความคุ้มค่า

  • GOB นำเข้าได้เร็วกว่า 5 เท่า เมื่อเทียบกับฟอร์แมตเดิม
    • ใช้เวลาน้อยลงมากเมื่อเทียบกับการสร้าง GOL จาก PBF
    • บนระบบสมัยใหม่สามารถ โหลดข้อมูลทั้งโลกได้ภายใน 3 นาที
    • ทำงานได้อย่างมีประสิทธิภาพแม้มีหน่วยความจำไม่เกิน 32GB ทำให้ โน้ตบุ๊กเก่าก็ประมวลผลได้ภายในไม่ถึงหนึ่งชั่วโมง
  • ตัวอย่างการเปรียบเทียบขนาด (PBF → GOB):
    • Planet: 65.4GB → 46.0GB (-29.7%)
    • France: 4.54GB → 2.84GB (-36.3%)
    • Japan: 2.13GB → 1.34GB (-37.0%)
  • ยิ่งข้อมูลหนาแน่นมาก ประสิทธิภาพการบีบอัดก็ยิ่งสูงขึ้น โดยพื้นที่ที่มีความหนาแน่นข้อมูลต่ำกว่า เช่น บราซิลและจีน จะลดขนาดได้ราว 23%

โครงสร้างและวิธีการใช้งาน

  • GOB ถูกจัดเป็น หน่วยไทล์ และเลียนแบบโครงสร้างซูมของตัวเรนเดอร์ไทล์แผนที่ (zoom 6~12)
    • ข้อมูลทั้งโลกประกอบด้วยประมาณ 60,000 ไทล์
    • สามารถดึงและรวมข้อมูลรายภูมิภาคได้ด้วยความเร็วระดับการคัดลอกไฟล์
  • ด้วยโครงสร้างนี้ การ เก็บรักษา แจกจ่าย และอัปเดตบางส่วนตามภูมิภาค จึงทำได้ง่าย

ข้อจำกัด

  • GOB ไม่รวมเมทาดาทา (เช่น ชื่อผู้แก้ไข, timestamp) และ ประวัติการแก้ไข
    • จึงเหมาะที่สุดสำหรับ การแจกจ่ายและการจัดเก็บถาวร มากกว่างานแก้ไข
    • หากต้องการคงข้อมูลให้ทันสมัย จำเป็นต้องสร้าง GOB snapshot ใหม่

วิธีใช้งาน

  • GOB ใช้งานได้ตั้งแต่ GOL Tool 2.1 ขึ้นไป
    • แปลง GOL เป็น GOB ด้วยคำสั่ง gol save <gol-file> [<gob-file>]
    • โหลด GOB เข้า GOL ด้วยคำสั่ง gol load <gol-file> [<gob-file>]
  • หากใช้ตัวเลือก --area จะสามารถ ส่งออก/โหลดเฉพาะบางพื้นที่ ได้ด้วย GeoJSON, WKT หรือพิกัด
    • ตัวอย่าง: 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

ชุดข้อมูลที่ให้บริการและแผนต่อไป

  • Open Planet Data แจกจ่าย ไฟล์ GOB ทั่วโลกที่อัปเดตรายวัน (ขนาดต่ำกว่า 50GB)
  • ผู้พัฒนายังคงปรับปรุงเพิ่มเติมต่อไป:
    • ทดลองใช้ อัลกอริทึมการบีบอัด อื่นนอกเหนือจาก zlib (zstd ยังไม่ให้ผลดีขึ้นอย่างมีนัยสำคัญ)
    • ในอนาคต gol load จะเพิ่ม ความสามารถในการโหลด GOB จาก URL โดยตรง
    • เป้าหมายคือการทำ การนำเข้าแทบเป็น 0 นาทีจริง ด้วย “การสร้างเบื้องหลังระหว่างดาวน์โหลด”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-26
ความคิดเห็นบน Hacker News

  • ลองไปค้นดูเพราะสงสัยสเปกของ ฟอร์แมต GOB แบบใหม่นี้ ยังไม่มีสเปกทางการในตอนนี้ แต่มีกระทู้ที่พูดถึงรายละเอียดอยู่
    ไม่ได้จำกัดแค่ OSM เท่านั้น แต่ฟอร์แมตข้อมูลเชิงพื้นที่ประสิทธิภาพสูงที่รองรับ spatial indexing มีผลอย่างมากต่อการใช้งานและ productivity ของแอป
    ตัวอย่างเช่น ถ้าบันทึกข้อมูลขนาดใหญ่ใน QGIS เป็น KMZ (zipped XML) โปรแกรมจะค้างไปหลาย分钟 แต่ถ้าบันทึกข้อมูลเดียวกันเป็น flatgeobuf จะโหลดได้ทันที

    • ความต่างน่าจะอยู่ที่ KMZ ไม่สามารถสตรีมได้ จึงต้องโหลดทั้งหมดเข้าเมมโมรีก่อน แล้วค่อยแปลงเป็นโครงสร้างภายในของ QGIS
      เคยเจอเหมือนกันว่า KMZ/KML ที่ซับซ้อนโหลดเข้า GIS แอปอื่นได้ไม่ค่อยดี
      เลยสงสัยว่าถ้าเขียนข้อมูลเดียวกันเป็น GeoJSON จะเป็นอย่างไร
    • ใน QGIS รู้สึกว่าการเอาข้อมูลขึ้น Postgres แล้วใช้งานนั้นดีกว่ามากในแง่ประสิทธิภาพ

  • สงสัยว่าฟอร์แมตนี้ใช้ OSM data model แบบใหม่หรือไม่
    มีข้อมูลที่เกี่ยวข้องคือรายงานวิจัย data model, GitHub repository, และโพสต์ในบล็อกทางการที่ขอฟีดแบ็ก
    ในโมเดลปัจจุบัน ขั้นตอนแปลงพิกัดเป็นการอ้างอิงโหนดนั้นช้าและกิน RAM มาก เลยค่อนข้างลำบาก

  • มีคำถามเกี่ยวกับ GIS กำลังหาวิธีที่ดีในการแปลง LIDAR point cloud ให้เป็น mesh
    บริเวณที่เกือบตั้งฉากอย่างผนังอาคารมีข้อมูลค่อนข้าง sparse และไม่มี point normal ทำให้วิธีทั่วไปอย่าง Poisson, Ball Pivot หรือ VCG ของ Meshlab ให้ผลลัพธ์ที่เสื่อมสภาพหรือช้าเกินไป
    แนวทางแบบ heightmap ตรง ๆ ก็มีข้อจำกัดเพราะมีทั้ง canopy ของต้นไม้และชายคา
    อยากลดจุดประมาณ 9 หมื่นล้านจุดให้เหลือสามเหลี่ยมราว 30 ถึง 50 ล้านรูป โดยไม่ต้องไปพัฒนา custom pipeline หลายเดือน

    • น่าลองดูโปรเจ็กต์ 3DBAG เป็นโครงการโอเพนซอร์สที่รีคอนสตรักต์อาคาร 11 ล้านหลังในเนเธอร์แลนด์จาก LiDAR และขอบเขตอาคาร
      มีทั้งGitHub repositoryและreconstruction pipelineเผยแพร่อยู่
    • ตอนนี้ Meshroom รับข้อมูล LIDAR เป็นอินพุตได้แล้ว
      เคยใช้กับงาน photogrammetry และ camera tracking สำหรับ VFX มาก่อน และเป็นชุดเครื่องมือโอเพนซอร์สที่แข็งแรงมากสำหรับงานลักษณะนี้

  • คิดว่าน่าจะยังเป็นฟอร์แมตรอง ๆ อยู่ ถ้า libosmium กับ GDAL ไม่รองรับ

    • แต่ก็ไม่ได้หมายความว่าพวกเขาจะไม่มีเหตุผลให้รองรับ
      ตอนนี้ยังเป็นแค่แนวคิดในระยะเริ่มต้นและยังไม่มีสเปกที่สมบูรณ์ ซึ่งฟอร์แมตใหม่ทุกตัวก็เริ่มต้นแบบนี้

  • สงสัยว่าเข้ากันได้กับ osmium หรือไม่

    • ยังไม่ใช่ ตอนนี้เพิ่งเปิดตัว และยังไม่มีแม้แต่สเปกอย่างเป็นทางการ