Comment convertir du GeoJSON en JSON (supprimer la géométrie, conserver les propriétés)
Ce que le GeoJSON contient vraiment (et pourquoi c'est plus que ce dont tu as besoin)
Le GeoJSON, c'est simplement du JSON, mais avec une structure très spécifique et souvent volumineuse. Chaque fichier encapsule généralement tes données dans une `FeatureCollection` qui contient un tableau d'objets `Feature`. Chaque `Feature`, à son tour, a deux parties principales : `geometry` et `properties`. Le bloc `geometry` est l'endroit où vivent toutes les données spatiales — les tableaux de coordonnées, les types de formes comme Point ou Polygon, et les anneaux de coordonnées complexes qui peuvent s'étendre sur des milliers de lignes. Le bloc `properties` est ce qui t'intéresse généralement : les véritables données attributaires comme les noms, les identifiants, les décomptes de population ou les horodatages liés à chaque forme. Cette structure devient un problème lorsque tu dois transmettre les données à un système qui ne parle pas le langage des cartes. Imagine que tu as exporté un jeu de données de toutes les limites des 4 200 comtés américains à partir d'un outil SIG. Le fichier GeoJSON résultant pourrait facilement faire 18 Mo, chaque polygone de comté étant défini par des milliers de paires de coordonnées. Si ton objectif est juste d'utiliser le nom du comté, le code FIPS et la population dans un rapport ou une API, tu te trimballes avec 95 % de poids mort. Cette géométrie n'est que du bruit. Pire encore, certains analyseurs rejetteront catégoriquement un fichier parce qu'ils ne reconnaissent pas les clés géospatiales. Pour ces usages non spatiaux, supprimer la géométrie, ce n'est pas perdre des données ; c'est simplement une préparation intelligente des données.
La différence de structure : GeoJSON vs JSON simple
Soyons plus précis sur la transformation. Voici un `Feature` GeoJSON minimal avec lequel tu pourrais commencer : { "type": "Feature", "geometry": { "type": "Point", "coordinates": [-87.6298, 41.8781] }, "properties": { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } } Après avoir supprimé la géométrie, ta cible est l'objet JSON propre et simple imbriqué dans la clé `properties` : { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } Lorsque ton entrée est une `FeatureCollection` (un fichier avec plusieurs entités), l'objectif est de produire un unique tableau JSON contenant juste les objets de propriétés de chaque entité : [ { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" }, { "city": "Houston", "population": 2304580, "timezone": "America/Chicago" } ] C'est le format que la plupart des API, des importateurs de feuilles de calcul et des chargeurs de bases de données sont conçus pour comprendre. Quiconque a déjà débogué un appel API qui plante connaît la frustration d'un analyseur qui bute sur des clés de haut niveau inattendues comme `geometry` ou `type`. Le résultat final est un tableau JSON propre, prêt à fonctionner avec presque n'importe quel outil. Un détail crucial : que se passe-t-il si une entité a une valeur `null` pour ses `properties` ? C'est du GeoJSON valide. Un bon convertisseur produira un objet vide `{}` pour cette entité au lieu de planter ou, pire, de l'ignorer en silence. Les convertisseurs bâclés échouent systématiquement à ce test.
Convertir du GeoJSON en JSON avec CocoConvert
Pour une solution rapide et sans code, le convertisseur GeoJSON vers JSON de CocoConvert sur /convert/geojson-to-json est conçu exactement pour cette tâche. Le processus est simple. Tu télécharges ton fichier `.geojson` ou `.json` (il accepte les deux extensions, car le GeoJSON utilise souvent `.json`), tu sélectionnes tes options, et tu télécharges le résultat épuré. Le convertisseur est impitoyable par défaut. Il trouve le tableau `features`, récupère l'objet `properties` de chaque entité, et les assemble dans un tableau JSON propre. La clé `geometry`, la clé `type` et l'enveloppe `FeatureCollection` sont toutes laissées de côté. Si ton fichier contient une seule `Feature` au lieu d'une collection, la sortie sera un unique objet JSON, pas un tableau. CocoConvert gère les fichiers jusqu'à 50 Mo dans la version gratuite, ce qui est amplement suffisant pour la plupart des jeux de données avec moins de 10 000 entités. Mais si tu as un fichier massif comme un réseau routier à l'échelle d'un État (qui peut facilement atteindre 200 Mo ou plus), tu devras utiliser un outil en ligne de commande, que nous aborderons ensuite. Pour la confidentialité, le convertisseur traite les fichiers sur le serveur mais ne stocke pas tes données après ta session, un détail important si tes attributs incluent des informations sensibles comme des identifiants personnels. Par défaut, le fichier téléchargé aura une extension `.json`. Le panneau de paramètres te donne plus de contrôle, te permettant de spécifier un nom de fichier personnalisé ou d'obtenir une sortie indentée et lisible par un humain au lieu d'une seule ligne minifiée.
Alternatives en ligne de commande pour les gros fichiers ou l'automatisation
Lorsque tu manipules des fichiers de plus de 50 Mo ou que tu as besoin d'automatiser cette conversion dans un script, la ligne de commande est ton amie. Tu as deux armes principales au choix : `jq` et le module `json` intégré de Python. Pour la transformation pure de JSON, rien ne bat `jq` en termes de vitesse et de simplicité : jq '[.features[].properties]' input.geojson > output.json Cette seule ligne fait exactement ce que l'outil web fait : elle parcourt chaque entité, en extrait l'objet `properties`, et enveloppe les résultats dans un tableau JSON. `jq` s'installe facilement sur n'importe quel OS majeur (comme `brew install jq` sur macOS ou `apt install jq` sur Debian/Ubuntu) et peut dévorer des fichiers de plusieurs gigaoctets sans broncher car il traite les données en flux continu au lieu de tout charger en mémoire. Si l'`id` de ton entité est important (en GeoJSON, il se trouve à côté de `properties`, pas à l'intérieur), tu peux le fusionner : jq '[.features[] | {id: .id} + .properties]' input.geojson > output.json Quand tu as besoin de plus de logique, Python est la solution : import json with open('input.geojson') as f: gj = json.load(f) result = [feature['properties'] for feature in gj['features']] with open('output.json', 'w') as f: json.dump(result, f, indent=2) Ce court script te donne un contrôle total pour filtrer des entités, renommer des clés ou gérer des cas particuliers étranges avant d'écrire la sortie. Mieux encore, le module `json` fait partie de la bibliothèque standard de Python, donc il n'y a rien de plus à installer. Laisse-moi être direct dans ma recommandation : utilise CocoConvert quand tu as un seul fichier et que tu veux un résultat en 30 secondes sans toucher au code. Utilise `jq` ou Python quand tu automatises un pipeline de données ou que tu traites des centaines de fichiers.
Gérer les cas particuliers qui plantent les convertisseurs naïfs
Le GeoJSON du monde réel est souvent plus désordonné que les exemples propres de la spécification. Voici les pièges courants qui peuvent faire planter un convertisseur naïf. **Géométrie nulle :** Tu rencontreras fréquemment des entités avec `"geometry": null`. Elles sont parfaitement valides, représentant souvent des enregistrements qui n'ont tout simplement pas de données de localisation. Un convertisseur robuste doit quand même extraire leurs propriétés, et non rejeter l'entité entière. Les méthodes `jq` et Python présentées plus tôt gèrent cela correctement. **Propriétés imbriquées :** L'objet `properties` lui-même peut contenir des objets JSON imbriqués, comme `"properties": {"address": {"street": "Main St"}}`. La suppression de la géométrie n'aplatit pas ces structures imbriquées ; elles sont préservées telles quelles. Si tu as besoin d'une structure complètement plate (pour un CSV, par exemple), c'est une transformation distincte que tu devras effectuer. **Clés incohérentes :** Il est courant que certaines entités d'une collection aient une clé `"name"` alors que d'autres non. Le tableau JSON résultant aura simplement des objets avec des formes différentes. C'est du JSON valide, mais cela peut perturber les systèmes fortement typés. CocoConvert extrait fidèlement ce qui est présent ; il n'essaiera pas de normaliser le schéma pour toi. **`GeometryCollection` :** Certains fichiers utilisent un type `GeometryCollection`, qui a une structure différente de la `FeatureCollection` standard. De nombreux outils, y compris CocoConvert, s'attendent à une `FeatureCollection` et peuvent échouer s'ils rencontrent une `GeometryCollection` au niveau supérieur. **Problèmes d'encodage :** C'est un casse-tête classique des données SIG. La spécification GeoJSON impose l'encodage UTF-8, point final. Mais les fichiers exportés depuis d'anciens logiciels peuvent parfois contenir des caractères Latin-1 ou Windows-1252. Cela provoquera des erreurs d'analyse. Tu dois corriger l'encodage en amont à l'aide d'un outil comme `iconv` avant de tenter la conversion.
Quand faut-il garder la géométrie (et convertir différemment)
Bien que la suppression de la géométrie soit idéale pour les flux de travail axés uniquement sur les données, c'est parfois une très mauvaise idée. Il y a de nombreuses situations où tu as besoin de conserver les données spatiales, mais sous une forme différente. Si tu fournis des données à une bibliothèque de cartographie web comme Leaflet ou MapboxGL, arrête-toi. Ne convertis rien. Ces deux bibliothèques consomment le GeoJSON nativement, donc une conversion en JSON simple supprimerait les coordonnées mêmes dont elles ont besoin pour dessiner ta carte. Parfois, tu as besoin des coordonnées, mais sous une forme différente — comme un tableau plat d'objets `{lat, lng, name}` pour un graphique personnalisé. C'est une tâche de remodelage, pas de suppression de géométrie. `jq` est parfait pour cela : jq '[.features[] | {lat: .geometry.coordinates[1], lng: .geometry.coordinates[0], name: .properties.name}]' input.geojson > output.json Fais très attention à l'ordre des coordonnées ici. Le GeoJSON est strictement `[longitude, latitude]`, ou (x, y). C'est l'inverse de ce à quoi s'attendent beaucoup de gens et de systèmes. Se tromper est l'erreur la plus courante lors de la manipulation manuelle des coordonnées GeoJSON, et cela a l'effet à la fois hilarant et frustrant de placer tes données dans le mauvais hémisphère. Si ton objectif est de convertir du GeoJSON vers un autre format géospatial comme TopoJSON, Shapefile ou KML, tu as besoin d'un outil différent. CocoConvert ne fait pas ces conversions qui préservent la géométrie. Pour cela, tu devrais utiliser un outil spécialisé comme le puissant outil en ligne de commande `ogr2ogr` (de GDAL) ou l'excellent outil web Mapshaper. Ce sont les bons outils pour ce travail. Notre outil GeoJSON vers JSON sur /convert/geojson-to-json est ultra-spécialisé sur une seule tâche : extraire les propriétés. Il fait cette seule chose, et il la fait bien.
Valider ton fichier de sortie avant de l'utiliser en aval
Avant d'injecter ton nouveau fichier JSON tout propre dans un système en aval, prends deux minutes pour le valider. Cette étape simple peut t'éviter des heures de débogage de pannes déroutantes plus tard. Ouvre le fichier dans un éditeur de texte. Le niveau supérieur est-il un tableau (il commence par `[`) ? Chaque élément est-il un objet (commençant par `{`) ? Point crucial, vois-tu des clés `geometry` ou `type` ? Tu ne devrais pas. Une recherche rapide de la chaîne de caractères 'coordinates' ne devrait donner aucun résultat. Ensuite, vérifie le nombre d'enregistrements. Si ton GeoJSON d'entrée avait 847 entités, ton tableau JSON de sortie doit avoir exactement 847 objets. Si les chiffres ne correspondent pas, le convertisseur a laissé tomber des entités, probablement à cause d'une entrée malformée ou d'une mauvaise gestion des valeurs nulles. Maintenant, vérifie les données au hasard. Compare les valeurs des propriétés du premier, du dernier et d'un enregistrement du milieu choisi au hasard dans ton nouveau JSON avec le fichier GeoJSON original. Si les noms, les identifiants et les nombres correspondent tous, tu peux être sûr que la conversion a été propre. Pour les pipelines automatisés, utilise JSONSchema. Des outils comme `ajv` pour Node.js ou `jsonschema` pour Python te permettent de vérifier par programmation que chaque objet de ton tableau possède les clés et les types de données que tu attends. C'est essentiel pour tout processus qui s'exécute régulièrement sur des données changeantes. Et une dernière chose : si les données sont destinées à une base de données, exécute une requête `COUNT` sur la table après l'importation. Le nombre de lignes correspond-il à ce que tu attendais ? Cette vérification de 30 secondes est la confirmation ultime que toute la chaîne — conversion et importation — a parfaitement fonctionné.