- Para lidar com o vasto conjunto de dados do OpenStreetMap (OSM) no mundo todo de forma mais rápida e eficiente, foi introduzido o novo formato de arquivo GOB (Geo-Object Bundle)
- O GOB é uma versão compactada da Geo-Object Library (GOL) existente, removendo índices para reduzir o tamanho e aumentar a velocidade de processamento
- Arquivos GOB são, em média, 30% menores que PBF e têm cerca de metade do tamanho do GOL, com velocidade de importação 5x maior
- Com uma estrutura baseada em tiles, facilita extração e mesclagem por região, além de permitir carregamento rápido mesmo em sistemas modestos
- Embora não inclua metadados nem histórico de edições, mostra alta utilidade como formato para distribuição e arquivamento
Visão geral do formato GOB
- GOB é um novo formato de arquivo para lidar com dados do OpenStreetMap (OSM) de forma menor e mais rápida
- Tem metade do tamanho do GOL existente e é, em média, 30% menor que PBF
- Adota uma estrutura compactada e baseada em tiles para processamento de grandes volumes de dados
- O GOB faz parte do GeoDesk Toolkit e é oferecido como open source
- A versão
GOL Tool 2.1 oferece suporte para salvar (save) e carregar (load) GOB
Desempenho e eficiência
- O GOB é 5x mais rápido para importar do que os formatos existentes
- Reduz significativamente o tempo em comparação com a construção de GOL a partir de PBF
- Em sistemas modernos, carrega os dados do planeta inteiro em 3 minutos
- Funciona com eficiência mesmo com memória abaixo de 32GB, permitindo processamento em menos de uma hora até em notebooks antigos
- Exemplo de comparação de tamanho (PBF → GOB):
- Planet: 65.4GB → 46.0GB (-29.7%)
- France: 4.54GB → 2.84GB (-36.3%)
- Japan: 2.13GB → 1.34GB (-37.0%)
- Quanto mais densos os dados, maior a eficiência de compressão; regiões com menor densidade de dados, como Brasil e China, ficam em torno de 23% de redução
Estrutura e forma de uso
- O GOB é composto por tiles e imita a estrutura de zoom (zoom 6~12) dos renderizadores de tiles de mapa
- Os dados do planeta inteiro são compostos por cerca de 60 mil tiles
- É possível extrair e mesclar dados por região em velocidade próxima à de cópia de arquivo
- Graças a essa estrutura, armazenamento regional, distribuição e atualização parcial se tornam simples
Limitações
- O GOB não inclui metadados (nome do editor, timestamp etc.) nem histórico de alterações
- É otimizado não para edição, mas para distribuição e arquivamento
- Para manter os dados atualizados, é necessário recriar um novo snapshot GOB
Como usar
- O GOB pode ser usado no
GOL Tool 2.1 ou superior
- Converta GOL em GOB com o comando
gol save <gol-file> [<gob-file>]
- Carregue GOB em GOL com o comando
gol load <gol-file> [<gob-file>]
- Ao usar a opção
--area, é possível exportar/carregar apenas uma região específica com GeoJSON, WKT ou coordenadas
- Exemplo:
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
Datasets disponíveis e planos futuros
- O Open Planet Data distribui um arquivo GOB global atualizado diariamente (menos de 50GB)
- Os desenvolvedores seguem trabalhando em melhorias adicionais:
- Testes com algoritmos de compressão além de zlib (zstd não trouxe melhora significativa)
- No futuro,
gol load deverá adicionar suporte para carregar GOB diretamente de uma URL
- Com isso, a meta é alcançar importação efetiva em 0 minuto com “build em segundo plano em paralelo ao download”
1 comentários
Comentários no Hacker News
Fiquei curioso sobre a especificação do novo formato GOB e fui procurar. Ainda não existe uma especificação oficial, mas há uma discussão com detalhes
Não se limita ao OSM: um formato de dados espaciais de alto desempenho com suporte a indexação espacial tem grande impacto na usabilidade e na produtividade dos aplicativos
Por exemplo, no QGIS, salvar dados grandes como KMZ (XML compactado) faz o programa travar por vários minutos, mas salvar os mesmos dados em flatgeobuf faz com que carreguem imediatamente
Já tive experiências em que KMZ/KML complexos também não eram carregados direito em outros aplicativos GIS
Fico curioso para saber como seria com os mesmos dados em GeoJSON
Fico me perguntando se esse formato usa um novo modelo de dados do OSM
Como material relacionado, há o relatório de pesquisa sobre o modelo de dados, o repositório no GitHub e o post no blog oficial pedindo feedback
No modelo atual, o processo de converter coordenadas em referências de nós é lento e consome muita RAM, o que é inconveniente
Tenho uma pergunta relacionada a GIS. Estou procurando uma boa forma de transformar uma nuvem de pontos LIDAR em uma malha
Em áreas quase verticais, como paredes de edifícios, os dados são esparsos e não há normais dos pontos, então métodos comuns como Poisson, Ball Pivot ou VCG do Meshlab geram resultados degenerados ou são lentos demais
A cobertura de árvores e os beirais também limitam uma abordagem simples de heightmap
Quero reduzir cerca de 90 bilhões de pontos para algo entre 30 e 50 milhões de triângulos, mas gostaria de resolver isso sem passar meses desenvolvendo um pipeline customizado
O repositório no GitHub e o pipeline de reconstrução também estão disponíveis
Já usei antes para fotogrametria e camera tracking para VFX, e era um conjunto de ferramentas open source muito sólido para esse tipo de trabalho
Na minha opinião, se libosmium e GDAL não derem suporte, esse formato provavelmente continuará sendo algo periférico
Ainda está no estágio de ideia, sem nem mesmo uma especificação finalizada, então todo formato novo começa assim
Fico curioso para saber se isso é compatível com osmium