▲

OSM의 새로운 파일 형식 GOB, PBF보다 30% 작고 가져오기는 5배 빠름

 (community.openstreetmap.org)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 전 세계적으로 방대한 OpenStreetMap(OSM) 데이터셋을 더 빠르고 효율적으로 다루기 위해 새로운 파일 형식 GOB(Geo-Object Bundle) 이 도입됨
  • GOB는 기존 Geo-Object Library(GOL) 의 압축 버전으로, 인덱스를 제거해 크기를 줄이고 처리 속도를 높인 형태
  • GOB 파일은 PBF보다 평균 30% 작고, GOL보다 절반 수준이며, 가져오기 속도는 5배 빠름
  • 타일 기반 구조로 지역 단위 추출과 병합이 용이하며, 저사양 시스템에서도 빠른 로딩이 가능
  • 메타데이터와 수정 이력은 포함되지 않지만, 배포·보관용 형식으로 높은 활용성을 보임

GOB 형식의 개요

  • GOB는 OpenStreetMap(OSM) 데이터를 더 작고 빠르게 다루기 위한 새로운 파일 형식임
    • 기존의 GOL보다 절반 크기, PBF보다 평균 30% 더 작음
    • 대용량 데이터 처리를 위한 압축 및 타일 기반 구조를 채택함
  • GOB는 GeoDesk Toolkit의 일부로, 오픈소스로 제공됨
    • GOL Tool 2.1 버전에서 GOB 저장(save)과 불러오기(load) 기능을 지원함

성능 및 효율성

  • GOB는 기존 포맷보다 가져오기 속도가 5배 빠름
    • PBF로부터 GOL을 구축하는 데 걸리는 시간 대비 크게 단축됨
    • 최신 시스템에서는 행성 전체 데이터를 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)를 모방함
    • 행성 전체 데이터는 약 6만 개 타일로 구성됨
    • 지역별 데이터를 파일 복사 수준의 속도로 추출 및 병합 가능함
  • 이러한 구조 덕분에 지역별 보관, 배포, 부분 갱신이 간편함

제약 사항

  • GOB는 메타데이터(편집자 이름, 타임스탬프 등)와 수정 이력을 포함하지 않음
    • 편집 용도가 아닌 배포 및 아카이브 목적에 최적화됨
    • 최신 데이터를 유지하려면 새 GOB 스냅샷을 재생성해야 함

사용 방법

  • GOB는 GOL Tool 2.1 이상에서 사용 가능함
    • gol save <gol-file> [<gob-file>] 명령으로 GOL을 GOB로 변환
    • gol load <gol-file> [<gob-file>] 명령으로 GOB를 GOL에 불러오기
  • --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가 URL에서 직접 GOB를 불러오는 기능을 추가 예정
    • 이를 통해 “다운로드와 병행한 백그라운드 빌드”로 실질적 0분 임포트 목표를 달성하려 함
▲
GN⁺ 6시간전  [-]
Hacker News 의견

  • 새 GOB 포맷의 스펙이 궁금해서 찾아봤음. 아직 공식 스펙은 없지만, 세부 내용을 다룬 스레드가 있음
    OSM에 한정되지 않고, 공간 인덱싱을 지원하는 고성능 공간 데이터 포맷은 앱의 사용성과 생산성에 큰 영향을 줌
    예를 들어, QGIS에서 큰 데이터를 KMZ(zipped XML)로 저장하면 수 분 동안 멈추지만, 같은 데이터를 flatgeobuf로 저장하면 즉시 로드됨

    • KMZ는 스트리밍 불가라서 전체를 메모리에 올린 뒤 QGIS 내부 구조로 변환해야 하는 게 차이일 것 같음
      복잡한 KMZ/KML은 다른 GIS 앱에서도 잘 안 불러와졌던 경험이 있음
      같은 데이터를 GeoJSON으로 쓰면 어떤지 궁금함
    • QGIS에서는 데이터를 Postgres에 올려서 쓰는 게 성능상 훨씬 낫다고 느꼈음

  • 이 포맷이 새로운 OSM 데이터 모델을 사용하는지 궁금함
    관련 자료로 데이터 모델 연구 보고서, GitHub 저장소, 공식 블로그의 피드백 요청 글이 있음
    현재 모델에서 좌표를 노드 참조로 변환하는 과정이 느리고 RAM을 많이 소모해서 번거로움

  • GIS 관련 질문이 있음. LIDAR 포인트 클라우드를 메쉬로 만드는 좋은 방법을 찾고 있음
    건물 벽면처럼 수직에 가까운 곳은 데이터가 희소하고, 포인트 노멀도 없어서 Poisson이나 Ball Pivot, Meshlab의 VCG 같은 일반적인 방법들이 퇴화된 결과를 내거나 너무 느림
    수목 캐노피나 처마 때문에 단순한 heightmap 접근도 한계가 있음
    약 900억 개의 포인트를 3천만~5천만 개의 삼각형으로 줄이고 싶은데, 커스텀 파이프라인을 몇 달씩 개발하지 않고 해결하고 싶음

    • 3DBAG 프로젝트를 시도해볼 만함. 네덜란드의 1,100만 개 건물을 LiDAR와 건물 외곽선으로 재구성한 오픈소스 프로젝트임
      GitHub 저장소와 재구성 파이프라인도 공개되어 있음
    • Meshroom이 이제 LIDAR 데이터를 입력으로 받을 수 있음
      예전에 포토그래메트리와 VFX용 카메라 트래킹에 썼는데, 이런 작업에 매우 탄탄한 오픈소스 툴셋이었음

  • 내 생각에는 libosmium과 GDAL이 지원하지 않으면 이 포맷은 여전히 주변적인 존재로 남을 것 같음

    • 그렇다고 해서 그들이 지원하지 않을 이유가 있는 건 아님
      아직 완성된 스펙도 아닌 아이디어 단계이므로, 모든 새로운 포맷이 처음엔 이런 상황임

  • 이게 osmium과 호환되는지 궁금함

    • 아직 아님. 이제 막 소개된 포맷이라 정식 스펙조차 없음
답변달기