Pourquoi convertir du GeoJSON en GeoParquet
Le GeoJSON est facile à lire et facile à écrire à la main, ce qui explique pourquoi il est devenu le format par défaut pour partager des données cartographiques sur le web. Mais cette même simplicité devient un coût dès qu'un jeu de données dépasse quelques milliers d'entités. Le GeoJSON stocke chaque coordonnée sous forme de texte brut à l'intérieur d'une structure JSON, et un lecteur doit analyser le fichier entier, accolade par accolade, avant de pouvoir consulter ne serait-ce qu'une seule propriété. Impossible de ne lire que les colonnes dont on a besoin, et impossible de connaître l'emprise d'un fichier sans l'ouvrir et le parcourir en entier.
Le GeoParquet résout ce problème en empruntant le stockage en colonnes déjà utilisé par les ingénieurs de données pour les grands jeux de données tabulaires. Chaque propriété devient sa propre colonne, la géométrie devient une colonne binaire de valeurs WKB, et le fichier transporte un petit bloc de métadonnées qui indique dès le départ les types de géométrie et l'emprise globale. Un outil comme DuckDB ou GeoPandas peut alors ne lire que les colonnes réellement nécessaires à une requête, ignorer les fichiers dont l'emprise ne recoupe pas la zone d'intérêt, et s'appuyer sur la compression intégrée de Parquet pour réduire la taille des valeurs répétées comme des noms de lieux ou des codes de statut.
Cet outil existe pour supprimer les frictions de cette première étape. Plutôt que d'installer GDAL, un environnement Python ou un outil en ligne de commande, vous pouvez déposer un fichier GeoJSON dans votre navigateur et récupérer en quelques secondes un fichier GeoParquet fonctionnel. La conversion s'exécute côté client grâce à WebAssembly, si bien que l'outil fonctionne de la même façon que votre fichier compte dix entités ou cent mille, et vos données ne sont jamais envoyées où que ce soit.
GeoParquet : histoire, structure et repères
Le GeoParquet s'appuie sur Apache Parquet, un format de fichier orienté colonnes que Twitter et Cloudera ont publié en open source en 2013 pour le traitement de données à grande échelle sur Hadoop. Parquet en lui-même n'a aucune notion de ce qu'est une coordonnée : il se contente de stocker efficacement des colonnes typées, avec une compression par colonne et des métadonnées qui permettent à un lecteur d'ignorer des blocs entiers de données dont il n'a pas besoin.
La spécification GeoParquet ajoute des règles géospatiales par-dessus ce format généraliste. Elle a été développée par une communauté ouverte travaillant sous l'égide du Cloud-Native Geospatial Forum, la première version 1.0.0 ayant été publiée en août 2023. La version 1.1.0, publiée en 2024, a ajouté un support optionnel pour une colonne d'emprise par ligne et un champ "covering", tous deux destinés à permettre à un lecteur de filtrer des lignes sans décoder chaque géométrie.
Quelques repères utiles à connaître : le GeoParquet stocke la géométrie en WKB par défaut, si bien que n'importe quel langage disposant d'une bibliothèque WKB peut lire la colonne de géométrie même sans outillage spécifique à GeoParquet. La spécification suppose un ordre longitude/latitude en OGC:CRS84, sauf si un fichier indique un autre système de référence de coordonnées via PROJJSON. Et le GeoParquet a déjà largement dépassé le stade de l'expérimentation : Overture Maps, le projet de cartographie commun soutenu par Amazon, Meta, Microsoft et TomTom, publie l'intégralité de son jeu de données mondial (bâtiments, lieux, routes et limites administratives) au format GeoParquet, et Source Cooperative héberge des dizaines de jeux de données GeoParquet publics interrogeables directement depuis le stockage cloud.
En résumé, le GeoParquet n'est pas un nouveau modèle de géométrie. C'est un accord sur la façon de placer un encodage de géométrie déjà connu et bien compris à l'intérieur d'un format de fichier rapide et en colonnes, sur lequel le reste du monde de l'ingénierie des données s'appuie déjà.
Guide étape par étape
Choisissez un fichier .geojson sur votre ordinateur, collez du texte GeoJSON directement dans la zone prévue, ou cliquez sur "Essayer l'exemple" pour charger un petit fichier déjà prêt contenant des villes allemandes.
Une fois votre GeoJSON chargé, cliquez sur "Convertir en GeoParquet". La conversion s'exécute entièrement dans votre navigateur et se termine en une fraction de seconde pour des fichiers de taille courante.
Un résumé s'affiche : le nombre d'entités converties, les types de géométrie détectés, l'emprise, les colonnes de propriétés et la taille du fichier obtenu.
Les entités source sont dessinées sur la carte afin que vous puissiez confirmer que les bonnes données ont été converties avant de télécharger quoi que ce soit.
Cliquez sur "Télécharger converted.parquet" pour enregistrer le fichier GeoParquet obtenu sur votre ordinateur.
Six cas d'usage concrets
Les situations où le GeoParquet est réellement utilisé, au-delà du format de fichier lui-même.
- Publier de grands jeux de données ouverts. Des projets comme Overture Maps publient des jeux de données mondiaux de bâtiments et de lieux au format GeoParquet, car un seul fichier peut contenir des millions d'entités tout en restant rapide à interroger par région.
- Charger des données géospatiales dans un entrepôt de données cloud. BigQuery, Snowflake et DuckDB lisent tous nativement le Parquet. Convertir d'abord le GeoJSON en GeoParquet permet à la colonne de géométrie de se charger en même temps que le reste de la table, sans étape d'import séparée.
- Alimenter des pipelines d'apprentissage automatique. Les pipelines d'entraînement qui lisent de nombreux petits fichiers tirent parti de la structure en colonnes de Parquet : un modèle qui n'a besoin que des coordonnées et d'une seule colonne d'étiquette peut ignorer toutes les autres propriétés au lieu d'analyser un objet GeoJSON complet à chaque ligne.
- Archiver des jeux de données SIG municipaux et gouvernementaux. Les portails d'open data qui diffusent aujourd'hui des limites municipales, du zonage ou des données parcellaires en GeoJSON peuvent proposer en complément une copie GeoParquet, donnant aux analystes un fichier plus petit et plus rapide à interroger pour les mêmes données.
- Cataloguer les emprises d'images satellites et de télédétection. Les scènes et emprises de tuiles issues d'images satellites sont naturellement tabulaires : une géométrie plus des métadonnées comme la date de prise de vue et la couverture nuageuse par ligne, exactement la forme pour laquelle un format en colonnes comme Parquet est conçu.
- Prétraiter des données pour un pipeline de cartographie web. Les ingénieurs de données qui construisent des tuiles vectorielles ou des back-ends cartographiques mettent souvent d'abord en scène le GeoJSON brut sous forme de GeoParquet, car des outils en aval comme DuckDB spatial ou Apache Sedona peuvent filtrer et remodeler des millions d'entités bien plus vite qu'en réanalysant du texte JSON.
Questions et réponses techniques
Dix questions courantes sur le fonctionnement de ce convertisseur, avec des réponses directes.
1. Qu'est-ce que le GeoParquet, en termes simples ?
Le GeoParquet est une façon de stocker des données cartographiques (points, lignes, polygones et les informations qui leur sont associées) à l'intérieur d'un fichier Apache Parquet classique. Parquet est un format de fichier en colonnes conçu pour l'analytique rapide. Le GeoParquet ajoute simplement un petit ensemble de règles permettant à des colonnes de géométrie de vivre dans un fichier Parquet tout en restant lisibles correctement par des logiciels SIG.
2. Comment une géométrie est-elle réellement stockée dans le fichier ?
Chaque géométrie est encodée en WKB, l'abréviation de Well-Known Binary. Le WKB est une recette octet par octet : un octet indique si les nombres sont en little-endian ou en big-endian, quatre octets indiquent le type de géométrie (point, ligne, polygone, etc.), puis les coordonnées suivent sous forme de nombres bruts sur 8 octets. Cette valeur WKB est stockée dans une colonne binaire du fichier Parquet, une ligne par entité.
3. Un même fichier GeoParquet peut-il contenir plusieurs types de géométrie ?
Oui. Une seule colonne de géométrie peut mélanger points, lignes et polygones, car le WKB transporte son propre code de type à l'intérieur de chaque valeur. Ce convertisseur enregistre chaque type de géométrie rencontré dans une liste "geometry_types" au sein des métadonnées du fichier, afin qu'un lecteur sache à l'avance à quoi s'attendre sans avoir à parcourir chaque ligne.
4. Qu'est-ce que la clé de métadonnées "geo", et pourquoi est-elle importante ?
Chaque fichier GeoParquet transporte un petit objet JSON sous une clé de niveau schéma nommée "geo". Elle nomme la colonne de géométrie principale, indique l'encodage (WKB), liste les types de géométrie présents et donne l'emprise du fichier. Sans cette clé, un fichier Parquet n'est qu'une table d'octets. Avec elle, n'importe quel outil compatible GeoParquet sait exactement comment retransformer ces octets en géométries réelles.
5. Comment le GeoParquet se compare-t-il au GeoJSON en taille de fichier et en vitesse de lecture ?
Le GeoJSON stocke les coordonnées sous forme de texte, si bien qu'un nombre comme 13.404954 occupe neuf caractères. Le GeoParquet stocke ce même nombre sous forme d'un double binaire de 8 octets, puis Parquet compresse les motifs répétés sur l'ensemble de la colonne. Sur des jeux de données réels, cela produit couramment des fichiers 5 à 10 fois plus petits qu'en GeoJSON, et comme Parquet est orienté colonnes, une requête qui n'a besoin que d'une colonne de propriété peut carrément éviter de lire la géométrie.
6. Quel système de référence de coordonnées le GeoParquet utilise-t-il par défaut ?
Sauf indication contraire dans le fichier, un lecteur GeoParquet suppose que les coordonnées sont exprimées en longitude et latitude selon OGC:CRS84, soit le même ordre de coordonnées et le même datum que le GeoJSON standard. Ce convertisseur suit cette valeur par défaut, puisqu'il prend du GeoJSON en entrée.
7. Le fichier stocke-t-il une emprise pour l'ensemble du jeu de données ?
Oui. Ce convertisseur calcule une emprise glissante, X et Y minimum et maximum, au fur et à mesure qu'il traite chaque entité, et l'inscrit dans les métadonnées "geo" comme bbox de la colonne. Un lecteur peut vérifier cette seule bbox avant même de décider d'ouvrir le fichier, ce qui est utile pour filtrer de nombreux fichiers par zone.
8. Quels logiciels peuvent ouvrir le fichier .parquet produit par cet outil ?
Tout outil construit sur la spécification GeoParquet peut le lire : DuckDB avec son extension spatiale, GeoPandas, Apache Sedona, QGIS (versions récentes), et la plupart des entrepôts de données cloud qui prennent en charge Parquet avec un lecteur sensible à la géométrie par-dessus. Comme il s'agit en dessous d'un Apache Parquet ordinaire, même un lecteur Parquet non spatial peut ouvrir le fichier et voir la géométrie comme une colonne binaire.
9. La conversion fait-elle perdre de la précision sur les coordonnées ?
Non. Les coordonnées GeoJSON sont des nombres JSON, que JavaScript représente déjà en interne sous forme de flottants IEEE-754 en double précision. Le WKB stocke chaque coordonnée sous exactement le même double IEEE-754, si bien que la conversion est un réencodage binaire direct, et non une opération d'arrondi. L'aller-retour a été vérifié octet par octet pendant le développement.
10. Mon fichier GeoJSON est-il envoyé sur un serveur ?
Non. L'analyse du fichier, l'encodage WKB et l'écriture du Parquet s'exécutent tous à l'intérieur de votre navigateur grâce à WebAssembly. Votre fichier ne quitte jamais votre appareil, et aucune partie de la conversion ne passe par un serveur.
Les mathématiques derrière la conversion
La conversion ne comporte aucune ambiguïté ni aucune estimation. Chaque étape est une opération fixe et réversible sur des octets et des nombres, ce qui est précisément ce qui rend possible un aller-retour identique octet par octet. Voici ce qui se passe réellement avec vos données.
1. Les coordonnées sont déjà des doubles IEEE-754
Une coordonnée GeoJSON comme 13.404954 est analysée par l'analyseur JSON de JavaScript et transformée en un flottant IEEE-754 en double précision sur 64 bits : 1 bit de signe, 11 bits d'exposant et 52 bits de mantisse, ce qui donne environ 15 à 17 chiffres décimaux significatifs de précision. Le WKB stocke chaque coordonnée sous exactement ce même double de 8 octets, écrit en ordre little-endian. Aucun arrondi ni changement de format ne se produit ici : la conversion copie simplement les mêmes 64 bits déjà présents en mémoire dans le tampon de sortie.
2. Disposition et taille des octets en WKB
Chaque valeur WKB commence par un indicateur de boutisme sur 1 octet et un code de type de géométrie sous forme d'entier non signé sur 4 octets, si bien que l'en-tête fixe fait toujours 5 octets. Ensuite, la taille dépend du type de géométrie. Pour un anneau de n paires de coordonnées (utilisé par LineString et par chaque anneau d'un Polygon), 4 octets enregistrent le nombre de points, puis chaque paire coûte 16 octets (8 pour X, 8 pour Y) :
ring_bytes(n) = 4 + 16n Point = 5 + 16 = 21 bytes LineString(n) = 5 + ring_bytes(n) Polygon(rings) = 5 + 4 + Σ ring_bytes(ring) for each ring MultiPoint(n) = 5 + 4 + 21n (each point repeats the 5-byte header) MultiLineString = 5 + 4 + Σ (5 + ring_bytes(line)) for each line MultiPolygon = 5 + 4 + Σ (5 + 4 + Σ ring_bytes(ring)) for each polygon, each ring
C'est précis, pas approximatif : le convertisseur calcule la taille exacte en octets d'une géométrie avant d'allouer son tampon, écrit l'en-tête et chaque coordonnée à l'aide d'un DataView, et ne redimensionne jamais le tampon en cours d'écriture. Une simple ligne à deux points prend donc exactement 5 + 4 + 32 = 41 octets, à chaque fois, sur toutes les plateformes.
3. L'emprise se calcule en un seul passage linéaire
L'emprise [minX, minY, maxX, maxY] est calculée en visitant chaque paire de coordonnées exactement une fois et en conservant un minimum et un maximum glissants, une réduction en O(n) où n est le nombre total de paires de coordonnées sur toutes les entités. Il n'y a ni tri ni second passage : chaque nouvelle coordonnée n'a besoin d'être comparée qu'aux quatre valeurs glissantes, si bien que le coût du calcul de la bbox croît de façon linéaire avec la taille du jeu de données, jamais plus vite ni plus lentement.
4. Pourquoi le fichier obtenu est plus petit
Une paire de coordonnées GeoJSON comme [13.404954, 52.520008] occupe environ 20 octets en texte, crochets et virgule compris. La même paire sous forme de deux doubles WKB occupe exactement 16 octets, un gain modeste en soi. Le gain le plus important vient de l'encodage au niveau des colonnes de Parquet : une colonne de propriété textuelle, comme un nom de pays répété sur des milliers de lignes, se compresse extrêmement bien avec l'encodage par dictionnaire, puisque Parquet n'a besoin de stocker chaque chaîne distincte qu'une seule fois, plus une courte référence entière par ligne. Les colonnes numériques bénéficient de la même façon des encodages par plage de répétition et par compactage de bits lorsque les valeurs se répètent ou restent dans un intervalle étroit. Rien de tout cela n'est possible avec un format textuel orienté ligne comme le GeoJSON, où chaque valeur est réécrite en texte à chaque ligne.
Au final, le pipeline de conversion est déterministe à chaque étape : analyser un double IEEE-754 connu, l'écrire selon une disposition d'octets connue, suivre un minimum/maximum glissant, puis transmettre le résultat à un compresseur en colonnes généraliste. Ce déterminisme est exactement ce qui rend l'aller-retour sans perte, et c'est pourquoi le même fichier GeoJSON converti deux fois sur deux machines différentes produit une sortie GeoParquet identique, octet pour octet.
La conversion s'exécute entièrement dans votre navigateur grâce à Apache Arrow et à une compilation WebAssembly de parquet-wasm. Aucun fichier n'est jamais envoyé à un serveur. Tuiles de carte © contributeurs d'OpenStreetMap, dessinées avec Protomaps (hébergé par KONAKTIVE), avec CARTO en secours.
