Réponse courte

KML et GeoJSON résolvent des problèmes différents. KML est un format XML créé pour Google Earth : il regroupe géométrie et présentation — styles d'icônes, couleurs de lignes, règles d'étiquetage, HTML des infobulles, altitude, extrusions 3D et animation temporelle — afin que le fichier ait la même apparence partout où il s'ouvre. GeoJSON est un format JSON compact conçu pour le web : il porte la géométrie et de simples propriétés attributaires sans style, laissant l'apparence à l'application consommatrice. Les deux stockent les coordonnées en longitude-latitude WGS84.

Règle empirique : si le livrable est « ouvrez ceci et voyez exactement ce que je vois » — une carte de terrain, une vue pour partie prenante dans Google Earth — envoyez du KML (ou du KMZ, sa forme compressée). Si le livrable est une donnée qu'une application, une API ou une analyse va consommer et mettre en forme elle-même, envoyez du GeoJSON.

Structure : XML vs JSON

KML est du XML verbeux. Un seul point stylé :

<Placemark>
  <name>Adit 3</name>
  <styleUrl>#redIcon</styleUrl>
  <ExtendedData>
    <Data name="status"><value>collapsed</value></Data>
  </ExtendedData>
  <Point><coordinates>-2.41,53.48,310</coordinates></Point>
</Placemark>

La même entité en GeoJSON est plus légère et plus adaptée à la machine :

{
  "type": "Feature",
  "geometry": { "type": "Point", "coordinates": [-2.41, 53.48, 310] },
  "properties": { "name": "Adit 3", "status": "collapsed" }
}

Notez que les deux écrivent les coordonnées en longitude, latitude, (altitude) — la longitude en premier. Les inverser est l'erreur la plus courante lors de l'édition manuelle de l'un ou l'autre format, et cela fait silencieusement basculer les entités dans le mauvais hémisphère ou dans l'océan.

Système de coordonnées de référence

Aucun des deux formats ne vous laisse choisir une projection pour l'échange :

  • KML est défini par rapport à WGS84 (longitude, latitude, altitude en mètres au-dessus de l'ellipsoïde WGS84 ou par rapport au sol, selon altitudeMode).
  • GeoJSON, selon la RFC 7946, impose WGS84 (la variante CRS84, longitude avant latitude). L'ancien membre crs de la spec de 2008 est obsolète ; les parseurs modernes supposent WGS84 quoi qu'il arrive.

La conséquence pratique : si vos données sont dans un SCR projeté — disons UTM ou une grille nationale — vous devez reprojeter en WGS84 avant l'export vers l'un ou l'autre format. ogr2ogr -t_srs EPSG:4326 s'en charge. L'omettre produit des coordonnées comme 512000, 4601000 que les deux formats interpréteront comme des longitudes et latitudes absurdes.

Style et attributs

C'est là la véritable ligne de partage.

KML embarque la présentation. <Style> et <StyleMap> définissent les icônes, la largeur et la couleur des lignes (en hexadécimal aabbggrr — alpha d'abord, puis bleu-vert-rouge, un piège fréquent), le remplissage des polygones, l'échelle des étiquettes, et le HTML de <BalloonStyle> pour les infobulles. L'altitude, l'animation temporelle <gx:Track> et l'extrusion <Polygon> lui confèrent une véritable capacité 3D et temporelle. C'est pourquoi KML est la lingua franca de Google Earth et des exports de cartographie de terrain.

GeoJSON porte des données, pas une apparence. Les attributs vivent dans un objet properties plat — des paires clé-valeur propres, idéales pour le filtrage, la jointure et la liaison à une symbologie dans une carte web (Leaflet, MapLibre, OpenLayers) ou le traitement dans PostGIS, GDAL ou geopandas. Il n'y a pas de membre de style dans la spec ; si l'apparence doit voyager, vous l'encodez en propriétés que le client interprète, ou vous adoptez une convention comme simplestyle-spec (hors RFC 7946, prise en charge par certains visualiseurs tels que GitHub et Mapbox).

Donc : KML est meilleur quand l'image doit être autonome. GeoJSON est meilleur quand la donnée doit être interrogée, transformée ou re-stylée.

Taille et performance

Les balises XML de KML sont lourdes ; pour les grands jeux de données, il enfle rapidement, raison pour laquelle KMZ (un KML compressé, souvent avec icônes et superpositions empaquetées) existe et est généralement ce que vous livrez réellement. GeoJSON est plus léger par entité mais reste du texte non compressé sans index spatial, donc un GeoJSON de plusieurs mégaoctets étouffera un navigateur. Aucun des deux n'est un bon format de stockage analytique ou à grande échelle — pour cela, passez au GeoPackage, à PostGIS ou aux tuiles vectorielles. KML et GeoJSON sont tous deux des formats d'échange et de présentation, pas des entrepôts de données de travail.

Conversion détaillée avec ogr2ogr

KML vers GeoJSON (et reprojection par précaution, même si KML est déjà en WGS84) :

ogr2ogr -f GeoJSON sites.geojson sites.kml -t_srs EPSG:4326

GeoJSON vers KML :

ogr2ogr -f KML sites.kml sites.geojson

Reprojeter un shapefile UTM directement en GeoJSON pour le web :

ogr2ogr -f GeoJSON web.geojson utm.shp -t_srs EPSG:4326

Inspectez ce que vous avez produit avant de l'envoyer :

ogrinfo -so -al sites.geojson      # type de géométrie, nombre d'entités, champs, emprise

Surveillez : le style perdu (GeoJSON abandonne tout <Style> KML) ; les dossiers KML correspondant à des couches distinctes ; le mappage du schéma ExtendedData vers les propriétés GeoJSON ; et la bizarrerie d'ordre des couleurs (aabbggrr) si vous faites un aller-retour du style via KML.

Pièges courants et leurs causes

  • Inversion lng/lat. Les éditeurs et certains outils non conformes supposent lat/long ; KML comme GeoJSON sont en long/lat. Les entités atterrissent au mauvais endroit. Vérifiez face à un fond de carte après l'export.
  • Exporter des coordonnées projetées sans reprojeter. Des eastings/northings UTM écrits dans un format réservé au WGS84. Toujours -t_srs EPSG:4326.
  • S'attendre à ce que le style survive à l'aller-retour. KML → GeoJSON → KML perd les styles d'origine parce que GeoJSON ne les a jamais détenus.
  • Confusion des couleurs KML. <color> est en aabbggrr, pas rrggbbaa. Rouges et bleus s'inversent si vous supposez l'ordre hex du web.
  • Utiliser l'un ou l'autre pour les grosses données. Des dizaines de Mo de GeoJSON ou de KML bloqueront un navigateur ; déplacez les couches analytiques et volumineuses vers GeoPackage ou PostGIS et servez des tuiles au web.
  • Membre crs de GeoJSON. Ajouter un bloc crs non WGS84 est obsolète selon la RFC 7946 et ignoré par les parseurs modernes — reprojetez plutôt les données.

QA et validation

  • Lancez ogrinfo -so -al et confirmez que le nombre d'entités, le type de géométrie et l'emprise sont cohérents (coordonnées dans −180..180 et −90..90).
  • Ouvrez la sortie sur un fond de carte connu pour repérer visuellement une inversion de coordonnées.
  • Pour le KML, ouvrez dans Google Earth et confirmez que le style, le mode d'altitude et les infobulles s'affichent comme prévu.
  • Pour le GeoJSON, validez face à la RFC 7946 (règle de la main droite pour l'orientation des polygones, coordonnées WGS84) — ogr2ogr écrit une sortie conforme, les fichiers édités à la main ne le sont pas forcément.

Le point de vue Bathyl

Nous choisissons le format d'échange selon la destination, pas par habitude : KML ou KMZ quand une partie prenante a besoin d'une vue Google Earth autonome, GeoJSON quand une application web ou une API va consommer et re-styler les données. Pour tout ce qui est volumineux ou gourmand en requêtes, nous considérons les deux comme le mauvais outil et nous nous tournons vers GeoPackage ou un service de tuiles adossé à PostGIS.

Pour aller plus loin avec Bathyl

Sources