Định dạng tệp mới của OSM là GOB, nhỏ hơn PBF 30% và nhập nhanh hơn 5 lần

• Một định dạng tệp mới GOB (Geo-Object Bundle) đã được giới thiệu để xử lý bộ dữ liệu OpenStreetMap (OSM) khổng lồ trên toàn cầu nhanh hơn và hiệu quả hơn
• GOB là phiên bản nén của Geo-Object Library (GOL) hiện có, được tạo ra bằng cách loại bỏ chỉ mục để giảm kích thước và tăng tốc độ xử lý
• Tệp GOB nhỏ hơn PBF trung bình 30% và chỉ bằng một nửa GOL, đồng thời tốc độ nhập nhanh hơn 5 lần
• Với cấu trúc dựa trên tile, việc trích xuất và hợp nhất theo từng khu vực trở nên dễ dàng, đồng thời có thể tải nhanh ngay cả trên các hệ thống cấu hình thấp
• Dù không bao gồm metadata và lịch sử chỉnh sửa, định dạng này vẫn cho thấy tính hữu dụng cao cho mục đích phân phối và lưu trữ

---

Tổng quan về định dạng GOB

• GOB là định dạng tệp mới nhằm xử lý dữ liệu OpenStreetMap (OSM) nhỏ hơn và nhanh hơn
  • Chỉ bằng một nửa kích thước của GOL hiện có, và nhỏ hơn trung bình 30% so với PBF
  • Áp dụng cấu trúc nén và dựa trên tile cho xử lý dữ liệu quy mô lớn
• GOB là một phần của GeoDesk Toolkit và được cung cấp dưới dạng mã nguồn mở
  • Hỗ trợ chức năng lưu (save) và tải (load) GOB từ phiên bản GOL Tool 2.1

Hiệu năng và hiệu quả

• GOB có tốc độ nhập nhanh hơn 5 lần so với các định dạng hiện có
  • Thời gian cần để xây dựng GOL từ PBF được rút ngắn đáng kể
  • Trên các hệ thống hiện đại, có thể tải toàn bộ dữ liệu hành tinh chỉ trong 3 phút
  • Hoạt động hiệu quả ngay cả với bộ nhớ từ 32GB trở xuống, nên có thể xử lý trong vòng một giờ ngay cả trên laptop cũ
• Ví dụ so sánh kích thước (PBF → GOB):
  • Planet: 65.4GB → 46.0GB (-29.7%)
  • France: 4.54GB → 2.84GB (-36.3%)
  • Japan: 2.13GB → 1.34GB (-37.0%)
• Dữ liệu càng dày đặc thì hiệu quả nén càng cao; các khu vực có mật độ dữ liệu thấp như Brazil và Trung Quốc giảm khoảng 23%

Cấu trúc và cách sử dụng

• GOB được cấu thành theo đơn vị tile, mô phỏng cấu trúc zoom (zoom 6~12) của trình kết xuất tile bản đồ
  • Dữ liệu toàn hành tinh được cấu thành từ khoảng 60.000 tile
  • Có thể trích xuất và hợp nhất dữ liệu theo khu vực với tốc độ tương đương sao chép tệp
• Nhờ cấu trúc này, việc lưu trữ, phân phối và cập nhật từng phần theo khu vực trở nên đơn giản

Hạn chế

• GOB không bao gồm metadata (tên biên tập viên, timestamp, v.v.) và lịch sử chỉnh sửa
  • Được tối ưu cho mục đích phân phối và lưu trữ, không phải để chỉnh sửa
  • Để duy trì dữ liệu mới nhất, cần tạo lại snapshot GOB mới

Cách sử dụng

• GOB có thể dùng từ GOL Tool 2.1 trở lên
  • Chuyển GOL sang GOB bằng lệnh gol save <gol-file> [<gob-file>]
  • Tải GOB vào GOL bằng lệnh gol load <gol-file> [<gob-file>]
• Nếu dùng tùy chọn --area, có thể xuất/nhập chỉ một khu vực cụ thể bằng GeoJSON, WKT hoặc tọa độ
  • Ví dụ: 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

Bộ dữ liệu được cung cấp và kế hoạch sắp tới

• Open Planet Data phân phối tệp GOB toàn cầu được cập nhật hằng ngày (dưới 50GB)
• Nhà phát triển đang tiếp tục cải tiến thêm:
  • Thử nghiệm các thuật toán nén khác ngoài zlib (zstd không mang lại cải thiện đáng kể)
  • Trong tương lai, gol load sẽ bổ sung khả năng tải GOB trực tiếp từ URL
  • Qua đó hướng tới mục tiêu nhập thực tế mất 0 phút bằng “xây dựng nền chạy song song với quá trình tải xuống”

[GN⁺]

Ý kiến Hacker News

• Tôi đã tìm thử vì tò mò về đặc tả của định dạng GOB mới. Hiện vẫn chưa có đặc tả chính thức, nhưng có một chuỗi thảo luận nói về các chi tiết này
  Không chỉ giới hạn ở OSM, một định dạng dữ liệu không gian hiệu năng cao hỗ trợ lập chỉ mục không gian có ảnh hưởng rất lớn đến tính tiện dụng và năng suất của ứng dụng
  Ví dụ, nếu lưu dữ liệu lớn thành KMZ (XML nén) trong QGIS thì chương trình bị treo trong vài phút, nhưng nếu lưu cùng dữ liệu đó dưới dạng flatgeobuf thì tải gần như ngay lập tức

  • Có lẽ khác biệt là do KMZ không thể streaming, nên phải nạp toàn bộ vào bộ nhớ rồi chuyển đổi sang cấu trúc nội bộ của QGIS
    Tôi cũng từng gặp trường hợp KMZ/KML phức tạp không được các ứng dụng GIS khác tải tốt
    Tôi tò mò không biết nếu ghi cùng dữ liệu đó thành GeoJSON thì sẽ thế nào
  • Trong QGIS, tôi cảm thấy đưa dữ liệu lên Postgres để dùng cho hiệu năng tốt hơn hẳn

• Tôi tò mò không biết định dạng này có sử dụng mô hình dữ liệu OSM mới hay không
  Tài liệu liên quan gồm có báo cáo nghiên cứu mô hình dữ liệu, kho lưu trữ GitHub, và bài viết trên blog chính thức kêu gọi phản hồi
  Trong mô hình hiện tại, quá trình chuyển đổi tọa độ thành tham chiếu node khá chậm và tốn nhiều RAM, nên rất bất tiện

• Tôi có một câu hỏi liên quan đến GIS. Tôi đang tìm một cách tốt để biến point cloud LIDAR thành mesh
  Ở các khu vực gần như thẳng đứng như tường tòa nhà, dữ liệu thưa và cũng không có normal của điểm, nên các phương pháp phổ biến như Poisson, Ball Pivot hay VCG của Meshlab đều cho ra kết quả suy biến hoặc quá chậm
  Tán cây và mái hiên cũng khiến cách tiếp cận heightmap đơn giản có giới hạn
  Tôi muốn giảm khoảng 90 tỷ điểm xuống còn 30–50 triệu tam giác mà không phải mất hàng tháng để tự phát triển một pipeline tùy chỉnh

  • Có thể đáng để thử dự án 3DBAG. Đây là một dự án mã nguồn mở tái dựng 11 triệu tòa nhà ở Hà Lan từ LiDAR và đường bao tòa nhà
    Kho lưu trữ GitHub và pipeline tái dựng cũng được công khai
  • Meshroom giờ đã có thể nhận dữ liệu LIDAR làm đầu vào
    Trước đây tôi từng dùng nó cho photogrammetry và camera tracking trong VFX, và đây là một bộ công cụ mã nguồn mở rất vững chắc cho loại công việc này

• Theo tôi, nếu libosmium và GDAL không hỗ trợ thì định dạng này có lẽ vẫn sẽ chỉ là một lựa chọn bên lề

  • Tuy vậy, điều đó không có nghĩa là họ có lý do để không hỗ trợ
    Đây vẫn mới chỉ là giai đoạn ý tưởng, thậm chí còn chưa có đặc tả hoàn chỉnh, nên mọi định dạng mới ban đầu đều ở trong tình trạng như vậy

• Tôi tò mò không biết nó có tương thích với osmium không

  • Chưa. Đây là định dạng mới chỉ vừa được giới thiệu, nên thậm chí còn chưa có đặc tả chính thức