Les applications cartographiques prennent place parmi notre vie numérique grâce à leur utilité quotidienne. Si les GPS existent déjà depuis des décennies, les applications pour smartphone ont décuplé les possibilités avec la connexion à internet pour communiquer des points d’intérêts, des parcours, ou des événements dangereux sur la route. Les appareils photo sont désormais capables de taguer les images pour incorporer le lieu de prise de vue. Quant aux drones, ils sont capables d’enregistrer un journal de vol qui retrace le parcours de l’appareil. Le point commun de ces trois exemples technologiques ? Ils feront tous appel à un format d’échange de données géographiques.

GPX, le format par excellence du GPS

Le format GPX est l’acronyme de GPS eXchange Format, il est basé sur XML. C’est un format développé pour stocker en mémoire une succession de points qui pourront constituer trois types de données : points de cheminements, routes ou trace. La donnée de base (le point) est toujours la même mais il y a des variations dans le sens que doit prendre le fichier GPX.

Visualisation de la trace d’un drone avec GPX Viewer

Par exemple, la liste de points de cheminements (latitude, longitude, altitude) conviendra pour échanger des points de rendez-vous tout en laissant au GPS le soin d’optimiser l’itinéraire avec le trafic routier, l’important étant de se rendre aux points.

La route est utile pour ordonner logiquement les points de cheminement, et elle donne un sens à cette succession de points. L’espacement entre les points qui constituent la route n’a pas besoin d’être constant.

La trace consiste en un relevé de points qui est réalisé à intervalle de temps ou de distance fixe. On utilise les traces notamment pour effectuer des relevés topographiques permettant de modéliser des routes à partir de traces en conditions réelles.

En un seul format, nous avons donc trois variantes qui ont chacun un sens différent. Voici l’article Wikipedia qui décrit les données de base qui sont prévues dans le format GPX.

ITN, l’ancêtre de Tomtom

ITN est un format vieillissant et de moins en moins maintenu qui permet de lister une succession de points avec un champ de description. Son implémentation dans les GPS furent limitées à 32, 48, 100 puis 255 points d’intérêts. Cela est suffisant dans la plupart des cas pour des parcours routiers de voitures personnelles, mais cette limitation ne peut pas véritablement en faire un format d’échange.

Son format est extrêmement simple avec une précision fixe de 5 décimales, un champ de commentaire et une classification (4=départ , 0=étape, 2=arrivée).

KML, le format d’export de Google Earth et consorts

Le format KML (ou KMZ, KML gzippé) est basé sur XML, et issu des logiciels SIG sur ordinateur. Il permet d’exporter des données pour les représenter graphiquement dans un autre logiciel.

Ce format permet de stocker l’altitude des points, et cette information est généralement mieux respectée par les SIG qu’avec le format GPX. On peut dire que KML a une connotation 3D tandis que GPX est plutôt utilisé en 2D, même si ces deux formats contiennent la même information de base et peuvent mémoriser l’altitude (ou elevation).

La même trace en KMZ lue par Google Earth

Par conséquent pour retracer le vol d’un avion ou d’un drone, c’est le format KML qui permettra le plus facilement de représenter le parcours.

GeoJSON, le format pour les librairies cartographiques javascript

Le titres est un peu restrictif mais illustre bien l’état d’esprit de GeoJSON : c’est de piloter une librairie graphique comme Google Maps, Leaflet ou OpenLayers pour indiquer les données qui doivent être représentées sous forme d’aplats de couleur, de marqueurs ou de lignes brisées.

Le format GeoJSON n’est pas fait pour avoir un sens, mais joue le rôle de « partition » que doit jouer la librairie graphique pour représenter correctement les données. La société Mapbox a d’ailleurs élaboré une convention Simple Style pour étendre les possibilités de GeoJSON concernant la mise en forme des données.

La faiblesse de GeoJSON, c’est son manque de cadre directeur en ce qui concerne les propriétés de base. Du coup, si on en met un peu, le GeoJSON obtenu sera compatible avec les autres applications pour les éléments de base (marqueur, ligne, polygone) mais pas pour les propriétés avancées (mise en page, 3D, animations, associations, …) qui ne pourront pas être importées (properties de FeatureCollections) ou simplement pas exploitées (autres properties de Features). En outre, les polygones doivent être définies en tant que succession de coordonnées latitude-longitude, ce qui est beaucoup moins efficace qu’un encodage polyline alphanumérique.

La force de GeoJSON, c’est d’être compris pas les librairies graphiques comme des couches ou calques. Ainsi les groupes d’éléments restent associés dans les objets javascript.

A n’en pas douter, c’est un standard prometteur et évolutif que l’on croisera à l’avenir. Il existe déjà des extensions comme TopoJSON qui permet de rendre compte de la connexion des étapes entre elles.

Conclusion

En conclusion, chaque format correspond à une logique propre qu’il convient de diagnostiquer avant de faire un choix. Ainsi, sur l’application d’optimisation d’itinéraires Open Street que j’ai créé, ce sont les formats GPX et bientôt GeoJSON qui sont retenus, respectivement pour l’import GPS et l’import vers un logiciel géomatique.

Pour l’utilisateur, le choix d’un format plutôt qu’un autre se fera probablement sur des critères de compatibilité avec leurs logiciels préférés.