- Un nouveau format de fichier, GOB (Geo-Object Bundle), a été introduit pour manipuler plus rapidement et plus efficacement l’immense jeu de données OpenStreetMap (OSM) à l’échelle mondiale
- GOB est une version compressée de la Geo-Object Library (GOL) existante, dont les index ont été supprimés afin de réduire la taille et d’accélérer le traitement
- Les fichiers GOB sont en moyenne 30 % plus petits que les PBF, font environ la moitié de la taille des GOL, et leur vitesse d’import est 5 fois supérieure
- Grâce à une structure basée sur des tuiles, l’extraction et la fusion par zone géographique sont faciles, avec un chargement rapide même sur des systèmes modestes
- Les métadonnées et l’historique des modifications ne sont pas inclus, mais le format montre une forte utilité pour la distribution et l’archivage
Aperçu du format GOB
- GOB est un nouveau format de fichier conçu pour manipuler les données OpenStreetMap (OSM) de manière plus compacte et plus rapide
- Il fait la moitié de la taille d’un GOL classique et est en moyenne 30 % plus petit qu’un PBF
- Il adopte une structure compressée et basée sur des tuiles pour le traitement de données volumineuses
- GOB fait partie du GeoDesk Toolkit et est proposé en open source
- La version
GOL Tool 2.1 prend en charge l’enregistrement (save) et le chargement (load) des GOB
Performances et efficacité
- GOB offre une vitesse d’import 5 fois supérieure à celle des formats existants
- Le temps nécessaire est fortement réduit par rapport à la construction d’un GOL à partir d’un PBF
- Sur des systèmes récents, il est possible de charger les données de la planète entière en 3 minutes
- Le format fonctionne efficacement avec 32 Go de mémoire ou moins, ce qui permet aussi un traitement en moins d’une heure sur un ancien ordinateur portable
- Exemple de comparaison de taille (PBF → GOB) :
- Planet: 65.4GB → 46.0GB (-29.7%)
- France: 4.54GB → 2.84GB (-36.3%)
- Japan: 2.13GB → 1.34GB (-37.0%)
- Plus les données sont denses, meilleure est l’efficacité de compression ; dans des régions à plus faible densité de données comme le Brésil ou la Chine, la réduction est d’environ 23 %
Structure et usages
- GOB est organisé par tuiles et reproduit la structure de zoom (zoom 6~12) des moteurs de rendu de tuiles cartographiques
- Les données de la planète entière se composent d’environ 60 000 tuiles
- L’extraction et la fusion de données régionales sont possibles à une vitesse proche de celle d’une simple copie de fichier
- Cette structure facilite le stockage régional, la distribution et les mises à jour partielles
Limitations
- GOB n’inclut ni les métadonnées (nom de l’éditeur, horodatage, etc.) ni l’historique des modifications
- Il est optimisé non pas pour l’édition, mais pour la distribution et l’archivage
- Pour conserver des données à jour, il faut régénérer un nouveau snapshot GOB
Utilisation
- GOB est disponible à partir de
GOL Tool 2.1
- Convertir un GOL en GOB avec la commande
gol save <gol-file> [<gob-file>]
- Charger un GOB dans un GOL avec la commande
gol load <gol-file> [<gob-file>]
- L’option
--area permet d’exporter ou de charger uniquement une zone spécifique à partir de GeoJSON, WKT ou de coordonnées
- Exemple :
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
Jeux de données fournis et projets à venir
- Open Planet Data distribue un fichier GOB mondial mis à jour quotidiennement (moins de 50 Go)
- Les développeurs travaillent sur d’autres améliorations :
- Expérimentation d’algorithmes de compression autres que zlib (zstd n’apporte pas d’amélioration significative)
- Ajout prévu d’une fonction permettant à
gol load de charger directement des GOB depuis une URL
- L’objectif est ainsi d’atteindre un import effectif en 0 minute grâce à une « construction en arrière-plan pendant le téléchargement »
1 commentaires
Avis Hacker News
J’ai cherché les spécifications du nouveau format GOB par curiosité. Il n’y a pas encore de spécification officielle, mais il existe un fil de discussion qui entre dans les détails
Sans se limiter à OSM, un format de données spatiales haute performance avec prise en charge de l’indexation spatiale a un impact majeur sur l’utilisabilité et la productivité des applications
Par exemple, dans QGIS, enregistrer de gros volumes de données en KMZ (XML compressé) le bloque pendant plusieurs minutes, alors qu’en flatgeobuf, les mêmes données se chargent immédiatement
J’ai aussi déjà vu des KMZ/KML complexes mal s’importer dans d’autres applications SIG
Je me demande ce que ça donnerait avec les mêmes données en GeoJSON
Je me demande si ce format utilise un nouveau modèle de données OSM
Comme documentation connexe, il y a un rapport d’étude sur le modèle de données, un dépôt GitHub et un billet du blog officiel demandant des retours
Avec le modèle actuel, le processus qui convertit les coordonnées en références de nœuds est lent et consomme beaucoup de RAM, ce qui est pénible
J’ai une question liée aux SIG. Je cherche une bonne méthode pour transformer un nuage de points LIDAR en maillage
Dans les zones quasi verticales comme les façades de bâtiments, les données sont clairsemées et il n’y a pas de normales de points, donc les méthodes classiques comme Poisson, Ball Pivot ou le VCG de Meshlab produisent des résultats dégénérés ou sont trop lentes
La présence de canopées ou d’avant-toits limite aussi une approche simple en heightmap
J’aimerais réduire environ 90 milliards de points à 30 à 50 millions de triangles, sans devoir développer un pipeline sur mesure pendant des mois
Le dépôt GitHub et le pipeline de reconstruction sont également publics
Je l’ai déjà utilisé pour la photogrammétrie et le camera tracking pour les VFX, et c’était une boîte à outils open source très solide pour ce genre de travail
À mon avis, si libosmium et GDAL ne le prennent pas en charge, ce format restera malgré tout marginal
Ce n’est encore qu’une idée en cours d’élaboration, sans spécification finalisée, donc tous les nouveaux formats passent par cette phase au début
Je me demande si c’est compatible avec osmium