Dans les précédents articles de cette série, j'ai présenté trois difficultés courantes que je rencontre fréquemment dans les projets d'intégration géospatiale. J'ai également abordé, dans les deux articles précédents, l'importance de bien connaître ses données et de créer des métadonnées conformes aux normes . Dans ce dernier article, je me penche sur les données elles-mêmes, en soulignant l'importance de disposer de données structurées et normalisées, tout en reconnaissant que ce n'est pas toujours le cas.
Lorsqu'on souhaite intégrer des données vectorielles (points, polygones ou lignes, par exemple) issues d'un format non structuré comme un PDF, une vidéo ou une image, un prétraitement est nécessaire. Cela complexifie le processus ETL (Extraction, Transformation, Chargement) et peut entraîner une perte d'informations.
Cependant, j'ai rencontré des cas où aucune alternative n'était possible, les producteurs de données ne pouvant fournir d'informations que dans ces formats. Dans de tels cas, l'intelligence artificielle (IA) peut jouer un rôle précieux en aidant à extraire des éléments structurés à partir d'informations non structurées, grâce à des algorithmes tels que les réseaux de neurones convolutifs (CNN) pour la segmentation d'images.
Mais même lorsqu'on parle de formats structurés, tous les formats ne se valent pas.
L'image ci-dessous présente un classement des formats de données selon leur potentiel d'interopérabilité. Il est important de noter qu'il s'agit d'exemples illustratifs et non d'une liste exhaustive de tous les formats de données vectorielles existants.
Le format CSV est le moins recommandé, même s'il s'agit d'une norme ( RFC 4180 ). L'absence de schéma fixe complique la validation des informations. Ceci est particulièrement problématique pour les géométries, qui peuvent être encodées de diverses manières sans fournir d'information sur les systèmes de référence de coordonnées (SRC).
Shapefile est un format structuré et ouvert ; un livre blanc, publié en 1998, décrit ce format en détail, permettant à quiconque de l’implémenter (et il est d’ailleurs pris en charge par la plupart des outils géospatiaux). Cependant, cette spécification n’est pas une norme, car elle n’est ni développée ni maintenue par un organisme de normalisation indépendant. Par conséquent, elle n’offre pas le même niveau de garantie que les normes formelles.
Les trois formats restants, situés en haut de l'échelle, sont des standards et sont donc recommandés. GeoJSON et JSON-FG offrent une meilleure interopérabilité, car ils prennent en charge la validation sémantique via JSON Schema . JSON-FG, en particulier, permet la définition de FeatureTypes, définis par FeatureSchemas.
Quelques réserves doivent être prises en compte lors du choix des normes à l'aide de ce diagramme. JSON-FG est une norme relativement récente et son adoption n'est pas encore généralisée, tandis que GeoJSON utilise toujours le système de référence de coordonnées par défaut (WGS84).
Bien qu'il soit judicieux de recommander des formats plus interopérables, je reconnais que les utilisateurs arriveront souvent avec des formats différents. L'avantage est que, si nous travaillons avec des formats structurés, il est généralement simple de les convertir à l'aide d'outils tels que GDAL.
Mise en pratique de ces recommandations
Pour des conseils pratiques, consultez ces directives relatives aux formats de données, aux noms de fichiers et aux noms de champs. Ce guide propose une méthode pas à pas pour transformer des données tabulaires en un format de données géospatiales.
