Pourquoi des modèles de données communs sont-ils essentiels à un partage efficace de données IDS?

Les infrastructures de données spatiales (IDS) sont conçues et entretenues de manière à permettre le partage de données géospatiales publiées sur un SIG (la source) et consommées par un autre (la cible). Il existe de nombreuses façons de réaliser cet échange de données, y compris le téléchargement de données et la mise à disposition de services par l’intermédiaire de l’API REST d’ArcGIS. Toutefois, pour que l’échange de données soit à la fois efficace et efficient, il est important que les deux systèmes aient une interprétation commune du modèle dans lequel les données sont fournies. Un modèle d’échange de données géospatiales contient une définition de la géométrie, de la topologie, des attributs et de la sémantique, de sorte que les données cibles soient une représentation exacte des données sources. Lisez ce billet de blogue pour en savoir plus sur l’importance des modèles de données dans des échanges efficaces de données IDS.

L’objectif d’une IDS consiste à permettre le partage de données géospatiales au sein d’organisations et entre celles-ci. Il existe de nombreuses façons de déplacer des données géospatiales vectorielles d’un système à un autre, notamment le téléchargement de données, l’API REST d’ArcGIS, les services web de l’Open Geospatial Consortium (OGC), le format GeoPackage de l’OGC, des interfaces de programmation d’applications (API) et bien d’autres encore. Cependant, une fois les données à destination, comment le système cible les décode-t-il pour les utiliser aux fins de visualisation, d’intégration, de stockage et d’analyse? La structure des éléments d’information communiqués par le système source et la façon dont ils sont décodés par le système cible sont contrôlées par ce qu’on appelle un modèle de données géospatiales.

Dans son dictionnaire SIG, Esri définit ce « modèle de données » de trois façons :

• Dans les SIG, un modèle de données est une « construction mathématique permettant de représenter les objets géographiques ou les surfaces en tant que données. Par exemple, le modèle de données vectorielles représente la géographie sous forme de collections de points, de lignes et de polygones; le modèle de données matricielles représente la géographie sous forme de matrices de cellules qui stockent des valeurs numériques; et le modèle de données de réseaux triangulés irréguliers (TIN) représente la géographie sous forme d’ensembles de triangles contigus et non superposés. »
• Dans ArcGIS, un modèle de données est un « ensemble de spécifications de conception de base de données pour les objets d’une application SIG. Un modèle de données décrit les couches thématiques utilisées dans l’application (p. ex., casse-croûtes, routes et comtés); leur représentation spatiale (p. ex., point, ligne ou polygone); leurs attributs; leurs règles d’intégrité et leurs relations (p. ex., les comtés doivent être imbriqués dans des États); leur présentation cartographique; et la configuration requise des métadonnées. »
• En théorie de l’information, un modèle de données est une « description des règles par lesquelles les données sont définies, organisées, interrogées et mises à jour au sein d’un système d’information (généralement un système de gestion de bases de données) ».

Poussons plus loin notre réflexion : dans un contexte d’IDS, le modèle d’échange de données spatiales repose sur certains aspects cruciaux, notamment la géométrie, la topologie, les attributs et la sémantique. Examinons chacun de ces aspects.

La géométrie est la définition mathématique de la façon dont un objet est situé sur la surface de la Terre, sous elle ou au-dessus d’elle. La plupart des technologies SIG modernes fournissent la position d’un point sous la forme d’un uplet de coordonnées, par rapport au centre de la Terre et au temps. Le plus souvent, cette position correspond aux paires de coordonnées de latitude et de longitude basées sur un système de référence local, régional ou mondial (vertical et horizontal), comme expliqué ici et ici. Ainsi, pour rendre les données partagées aussi interopérables et précises que possible, il vaut mieux utiliser des coordonnées définies dans un système de référence mondial dont l’époque est connue. ArcGIS est capable de convertir les coordonnées entre différents systèmes de référence de coordonnées (SRC), comme un système de coordonnées géographiques (SCG), un système de coordonnées projetées (SCP), un système de coordonnées locales (SCL) ou un système de référence linéaire (SRL). Toutefois, pour des raisons de précision et d’interopérabilité, il est préférable d’échanger des données géospatiales à l’aide de coordonnées basées sur un SCG largement accepté, tel que le WGS-84, afin d’éviter tout risque d’erreur ou d’inexactitude de position lors de la conversion des coordonnées.

Il s’agit du processus qui serait exécuté automatiquement par ArcGIS pour convertir les coordonnées x-y projetées d’un fichier de données IDS entrant en coordonnées x-y projetées dans le SIG de destination (d’après une image tirée de ce document).

Parlons maintenant de la topologie dans le contexte de l’échange de données géospatiales. Dans sa définition purement mathématique, la topologie est l’étude des propriétés invariantes dans la déformation géométrique des objets et dans les transformations continues appliquées à des êtres mathématiques. Dans l’univers des SIG, « topologie » s’entend de la définition des relations spatiales entre des entités SIG afin que la représentation soit la plus précise possible. La topologie est importante pour de nombreuses raisons, dont certaines sont exposées dans cette publication. Aujourd’hui, nous disposons de nombreux outils dans ArcGIS pour corriger les erreurs topologiques. Mais on s’attend à une topologie plus précise et exacte que jamais auparavant. Avec l’abondance des données 3D et 4D générées et transmises, la topologie entre les entités spatiales doit être bien comprise et maintenue.

Avant de partager des données géospatiales, on doit s’assurer que les règles de topologie sont respectées pour éviter d’avoir des espaces vides, des chevauchements, des lignes pendantes et des sous-dépassements, et veiller à ce que les lignes et les polygones coïncident. Source de l’image : « ArcGIS 8.3 : la topologie appliquée à la géodatabase ».

Prochain sujet : les attributs. Le dictionnaire SIG d’Esri les décrit comme des « informations non spatiales concernant une entité géographique dans un SIG, généralement stockées dans une table et liées à l’entité par un identifiant unique. Les attributs d’un fleuve, par exemple, peuvent être son nom, sa longueur et sa charge sédimentaire à une station de mesure donnée. » Donc, chaque système impliqué dans l’échange de données SIG doit bien interpréter les valeurs des attributs. Dans l’exemple ci-dessus, il s’agirait de déterminer si le nom du fleuve est en anglais ou en français, si sa longueur est exprimée en miles ou en kilomètres ou encore si sa charge sédimentaire est indiquée en tonnes/jour ou en kilogrammes/heure. Pour que les attributs soient exploitables, il faut que les deux systèmes aient une compréhension commune des attributs et de leur définition.

Ces attributs représentant le niveau d’eau du rivage sont tirés de la couche de données ouvertes du Réseau hydro national – Série GéoBase. Chaque niveau d’eau est basé sur le système de référence. Source de l’image : Catalogue pour la production de données du Réseau hydro national (RHN).

Le dernier élément de notre liste est une compréhension commune de la sémantique des données. Il faut dire que les données SIG ont initialement été recueillies et utilisées dans un but précis, qu’elles ont ensuite été partagées par le biais d’une IDS, et que maintenant un nouvel utilisateur souhaite sûrement les exploiter dans un tout autre but. Ainsi, il y a un risque que l’utilisateur des données cibles interprète différemment les termes techniques employés par la personne qui a recueilli les données. D’où l’importance de la sémantique du domaine. Par exemple, le système de classification des terres humides du Canada définit cinq classes : les bogs, les fens, les marais, les marécages et les eaux peu profondes. Mais que se passe-t-il si on regroupe dans une IDS les données sur les terres humides de différents organismes? Les définitions des données sources (pour un bog, un marais ou un marécage) sont-elles les mêmes? Même chose dans les applications de transport : certaines données sont définies selon l’axe médian de la route, alors que d’autres systèmes cartographient la route selon l’axe médian des voies ou de l’emprise.

Voici un exemple de sémantique pour un réseau routier dont le jeu de données n’est pas uniforme quant à l’emplacement de l’axe médian. Ainsi, la route à gauche utilise un axe médian de route, tandis que celle à droite utilise un axe médian de voie. Comme les réseaux routiers peuvent être assez complexes, il est important d’avoir une sémantique commune dans un modèle de données commun afin d’assurer l’interopérabilité des données. Exemple tiré de la carte communautaire du Canada : Spécifications du réseau routier communautaire.

Créer et utiliser un modèle de données SIG vectorielles peut s’avérer long et compliqué, et un nouveau modèle de données ne garantit pas l’interopérabilité. En fait, un nouveau modèle représente souvent un obstacle à l’échange de données, car il doit être mis en œuvre et testé. Pour favoriser l’interopérabilité, il est préférable d’utiliser, en partie ou en totalité, un modèle éprouvé. Dans le contexte d’échange de données, on parle souvent de « formats de données ». Les gouvernements fournissent une grande quantité de données géospatiales. En général, ils investissent le temps et les ressources nécessaires pour élaborer des modèles à grande échelle. C’est le cas du gouvernement fédéral, qui a lancé la Série GéoBase. Ces modèles proposent diverses couches de données GéoBase (réseau routier, réseau hydrographique, réseau ferroviaire, toponymes, etc.). Esri Canada a pour sa part conçu le Modèle canadien de données municipales (MCDM). Le MCDM se configure pour répondre aux besoins précis d’une organisation. On peut personnaliser des thèmes spécifiques ou ajouter et modifier des champs et des alias de couche qui reflètent la terminologie utilisée dans une organisation et dans une application. D’autres formats (ou modèles de données) propres à certaines applications sont utilisés dans des secteurs comme la sécurité publique.

En conclusion, avoir des modèles de données communs (et clairs) est essentiel au partage de données IDS. Par ailleurs, l’organisation qui exploite les données tirées de l’IDS doit utiliser le même modèle que l’organisation source pour décoder les données (extraction, transformation, chargement). L’organisation cible doit aussi interpréter les concepts utilisés dans le modèle de données de la même façon que l’organisation source. Donc, si vous voulez maximiser l’interopérabilité de vos données avec une IDS, versez-les dans un modèle commun pour faciliter l’échange de données et réduire le risque d’erreurs. Voilà le secret du succès!

Ce billet a été écrit en anglais par Gordon Plunkett et peut être consulté ici.