- Se introdujo un nuevo formato de archivo, GOB (Geo-Object Bundle), para manejar el enorme conjunto de datos de OpenStreetMap (OSM) de forma más rápida y eficiente
- GOB es una versión comprimida de la Geo-Object Library (GOL) existente, con los índices eliminados para reducir el tamaño y aumentar la velocidad de procesamiento
- Los archivos GOB son en promedio 30% más pequeños que PBF, aproximadamente la mitad del tamaño de GOL, y su velocidad de importación es 5 veces mayor
- Su estructura basada en tiles facilita la extracción y fusión por regiones, y permite una carga rápida incluso en sistemas de bajos recursos
- Aunque no incluye metadatos ni historial de cambios, muestra gran utilidad como formato para distribución y archivado
Resumen del formato GOB
- GOB es un nuevo formato de archivo para manejar datos de OpenStreetMap (OSM) de forma más pequeña y rápida
- Tiene la mitad del tamaño de GOL y es en promedio 30% más pequeño que PBF
- Adopta una estructura comprimida y basada en tiles para el procesamiento de grandes volúmenes de datos
- GOB forma parte de GeoDesk Toolkit y se ofrece como código abierto
- La versión
GOL Tool 2.1 admite funciones para guardar (save) y cargar (load) GOB
Rendimiento y eficiencia
- GOB tiene una velocidad de importación 5 veces mayor que los formatos existentes
- Reduce de forma importante el tiempo comparado con la construcción de GOL a partir de PBF
- En sistemas modernos, carga los datos de todo el planeta en 3 minutos
- Funciona eficientemente incluso con 32GB o menos de memoria, por lo que puede procesarse en menos de una hora incluso en laptops antiguas
- Ejemplo de comparación de tamaños (PBF → GOB):
- Planet: 65.4GB → 46.0GB (-29.7%)
- France: 4.54GB → 2.84GB (-36.3%)
- Japan: 2.13GB → 1.34GB (-37.0%)
- Cuanto más densos sean los datos, mayor es la eficiencia de compresión; en regiones con menor densidad de datos, como Brasil y China, la reducción es de alrededor de 23%
Estructura y forma de uso
- GOB está compuesto por tiles y replica la estructura de zoom (zoom 6~12) de los renderizadores de tiles de mapas
- Los datos de todo el planeta están compuestos por aproximadamente 60 mil tiles
- Es posible extraer y fusionar datos regionales a una velocidad comparable a copiar archivos
- Gracias a esta estructura, se simplifican el almacenamiento por regiones, la distribución y las actualizaciones parciales
Limitaciones
- GOB no incluye metadatos (nombre del editor, marca de tiempo, etc.) ni historial de cambios
- Está optimizado no para edición, sino para distribución y archivado
- Para mantener datos actualizados, es necesario regenerar un nuevo snapshot de GOB
Cómo usarlo
- GOB puede usarse desde
GOL Tool 2.1 en adelante
- Convertir GOL a GOB con el comando
gol save <gol-file> [<gob-file>]
- Cargar GOB en GOL con el comando
gol load <gol-file> [<gob-file>]
- Con la opción
--area, es posible exportar/cargar solo una región específica usando GeoJSON, WKT o coordenadas
- Ejemplo:
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
Conjuntos de datos disponibles y planes futuros
- Open Planet Data distribuye diariamente archivos GOB globales (menos de 50GB) actualizados
- El desarrollador sigue trabajando en mejoras adicionales:
- Experimentar con otros algoritmos de compresión además de zlib (zstd no mostró mejoras significativas)
- En el futuro,
gol load añadirá la capacidad de cargar GOB directamente desde una URL
- Con eso, se busca lograr una importación efectiva de 0 minutos mediante una “construcción en segundo plano mientras se descarga”
1 comentarios
Comentarios de Hacker News
Me dio curiosidad la especificación del nuevo formato GOB y fui a buscarla. Todavía no hay una especificación oficial, pero hay un hilo que entra en detalles
No solo para OSM, un formato de datos espaciales de alto rendimiento con soporte para indexación espacial tiene un gran impacto en la usabilidad y productividad de las apps
Por ejemplo, en QGIS, si guardas datos grandes como KMZ (XML comprimido), se congela por varios minutos, pero si guardas los mismos datos como flatgeobuf, se carga de inmediato
He tenido experiencias en las que KMZ/KML complejos tampoco cargaban bien en otras apps GIS
Me pregunto cómo se comportaría si se escribiera el mismo conjunto de datos como GeoJSON
Me pregunto si este formato usa un nuevo modelo de datos de OSM
Como material relacionado, están este informe de investigación sobre el modelo de datos, el repositorio de GitHub y esta entrada del blog oficial pidiendo retroalimentación
En el modelo actual, el proceso de convertir coordenadas en referencias a nodos es lento y consume mucha RAM, lo que resulta engorroso
Tengo una pregunta relacionada con GIS. Estoy buscando una buena forma de convertir una nube de puntos LIDAR en una malla
En zonas casi verticales, como las paredes de los edificios, los datos son escasos, y como tampoco hay normales de punto, métodos comunes como Poisson, Ball Pivot o VCG de Meshlab producen resultados degenerados o son demasiado lentos
Por la cobertura arbórea o los aleros, un enfoque simple de heightmap también tiene limitaciones
Quiero reducir unos 90 mil millones de puntos a entre 30 y 50 millones de triángulos, pero me gustaría resolverlo sin pasar meses desarrollando un pipeline personalizado
También están públicos el repositorio de GitHub y el pipeline de reconstrucción
Antes lo usaba para fotogrametría y camera tracking para VFX, y era un toolkit open source muy sólido para este tipo de trabajo
En mi opinión, si libosmium y GDAL no lo soportan, este formato probablemente seguirá siendo algo periférico
Todavía está en fase de idea y ni siquiera hay una especificación terminada, así que todos los formatos nuevos empiezan así
Me pregunto si esto es compatible con osmium